Vigilante – Suite de seguridad 100% gratis: Cortafuegos, 2FA, login, cabeceras, escáner…

Registro de cambios

3.0.4

Corrige el aviso de contraseña caducada, que no aparecía cuando la contraseña caducaba durante una sesión abierta. Ahora lleva al usuario a la parte superior del perfil, donde se está el aviso. También arregla un bucle de redirección para los clientes en WooCommerce, y limita el acceso de una cuenta con contraseña caducada a su propio formulario de perfil.

• Mejorado: Cuando una contraseña ha caducado se redirige al usuario a la parte superior de su perfil, donde aparece un aviso explicando el motivo, en lugar de llevarlo directamente al campo de la contraseña, con el aviso oculto justo encima. El aviso incluye ahora un enlace al campo.
• Corrección: Faltaba el aviso de que una contraseña había caducado cuando vencía mientras el usuario seguía conectado. Se redirigía al usuario a su perfil sin ninguna explicación, y el aviso solo aparecía tras volver a iniciar sesión.
• Corrección: El último día antes de que caducara una contraseña no se mostraba el aviso, por lo que el cambio obligatorio se producía sin previo aviso el día anterior.
• Corrección: En una tienda con WooCommerce, una cuenta sin acceso al área de administración (por ejemplo, la de un cliente) cuyo perfil está en la lista de «Perfiles afectados» quedaba atrapada en un bucle de redirección cuando caducaba su contraseña. WooCommerce le redirigía desde el perfil a «Mi cuenta» y Vigilante le devolvía, por lo que no podía ni utilizar la tienda ni cambiar la contraseña. Ahora, a esa cuenta se le permite acceder a la pantalla de su perfil en el área de administración mientras el cambio está pendiente, y solo a esa pantalla. La contraseña se cambia allí, no en «Mi cuenta», y, una vez guardada, WooCommerce devuelve la cuenta a «Mi cuenta» como de costumbre.
• Corrección: Cuando había un cambio de contraseña pendiente se permitía el acceso a todas las solicitudes dirigidas a la pantalla de perfil, y desde esa pantalla se puede acceder a otros elementos: una página de plugins, un importador, una acción pasada en la dirección o el perfil de otro usuario en el caso de una cuenta con permiso para editar usuarios. Una cuenta con una contraseña caducada podía seguir utilizando esas funciones. Ahora solo se permite el acceso a su propio formulario de perfil, ya sea para visualizarlo o para guardarlo. En una red, las pantallas de perfil del administrador de la red y del escritorio del usuario conducen al perfil del sitio, donde se encuentra el aviso.
• Corrección: En un sitio cuya dirección de WordPress y dirección del sitio estén en servidores diferentes (por ejemplo, un sitio «headless») o cuya dirección contenga letras acentuadas o no latinas tal y como están escritas, un usuario con una contraseña caducada quedaba atrapado en un bucle de redirección. La redirección al perfil se trataba como una redirección al escritorio, lo que enviaba al usuario de nuevo al perfil. Ahora se accede correctamente al perfil.

3.0.3

Integridad de archivos ahora compara los temas con su paquete de WordPress.org, busca en todo el código que no tiene copia oficial y examina los plugins must-use, los drop-ins, wp-admin, wp-includes y el resto de wp-content. Los correos electrónicos del análisis se envían una vez por cada hallazgo nuevo.

• Mejorado: Integridad de archivos compara los temas de WordPress.org con el paquete que WordPress.org publica para la versión instalada. WordPress.org no tiene sumas de comprobación para los temas, así que hasta ahora ningún archivo de tema se comparaba con nada. El paquete se descarga una vez por versión.
• Mejorado: la integridad de archivos busca código oculto en todos los archivos PHP de un plugin o tema sin copia oficial, no solo en los primeros 50, y lee archivos de hasta 8 MB. Un archivo de más de 512.000 bytes no se abría, así que pasaba como limpio. Uno de más de 8 MB se lista como no analizado.
• Mejorado: la integridad de archivos examina los archivos añadidos a wp-admin y wp-includes, los plugins imprescindibles y los drop-ins, los archivos PHP sueltos en wp-content, y las carpetas con PHP entre los plugins o los temas que WordPress no lista como tal.
• Mejorado: la integridad de archivos busca código oculto en los archivos PHP de las demás carpetas de wp-content (languages, upgrade y similares). Un archivo de traducción que contenga algo distinto de texto se reporta, porque WordPress carga los archivos de traducción en cada solicitud.
• Mejorado: una instalación nueva ya no empieza con wp-content/cache entre las rutas excluidas, así que esa carpeta también se analiza. Un sitio que ya la tenga ahí la conserva.
• Mejorado: la integridad de archivos informa de un .htaccess, .user.ini o php.ini fuera de uploads que hace que el servidor ejecute código o cargue un archivo.
• Mejorado: la integridad de archivos encuentra, en código sin copia oficial, datos de la solicitud ejecutados como código o como comando, una función elegida por la solicitud y un archivo incluido desde otro servidor. No se informa del mismo texto en un comentario.
• Mejora: un archivo en el que la búsqueda de código oculto no puede terminar se lista como no analizado en lugar de pasar como limpio.
• Mejorado: la itegridad de archivos ahora compara wp-includes/version.php, y compara los sitios que no están en inglés con las sumas de comprobación en inglés mientras WordPress.org no tiene ninguna para su idioma, en lugar de dejar el núcleo sin comprobar.
• Mejorado: la integridad de archivos informa de los archivos borrados de un plugin o un tema, e informa de una solicitud fallida a WordPress.org como un error en lugar de tratar el plugin como uno sin copia oficial.
• Mejorado: la integridad de archivos informa de más tipos de archivo en la carpeta de subidas (.pht, .php8, nombres como shell.php.suspected, .user.ini, php.ini, scripts de shell y CGI), un .user.ini o php.ini en la raíz del sitio que carga un archivo en cada solicitud, además de copias de seguridad dejadas en la raíz del sitio.
• Mejora: la pestaña Integridad de archivos indica qué suele ser cada tipo de hallazgo y qué hacer al respecto, nombra los plugins y temas que no se han podido comparar, y dice cuándo un análisis fue parcial en lugar de decir que todos los archivos pasaron.
• Mejora: cuando un análisis agota el tiempo, Integridad de archivos y el correo electrónico del análisis nombran los plugins, los temas y las áreas a las que no llegó, e Integridad de archivos lista las carpetas que excluir para que un análisis manual llegue al resto. Un análisis se ejecuta durante 60 segundos como máximo y empieza desde el principio cada vez, así que en un sitio muy grande la misma parte se queda sin comprobar en cada análisis.
• Mejorado: la integridad de archivos y la comprobación de seguridad indican cuándo las rutas excluidas contienen la carpeta entera de un plugin o de un tema, o la carpeta de subidas. Ninguna exploración mira dentro de ellas, y la comprobación de seguridad ya no cuenta un análisis así como limpio.
• Mejorado: La integridad de archivos y la comprobación de seguridad indican cuándo ningún análisis programado ha terminado durante más tiempo del que permite la programación. Una epxloración que el servidor detiene a medias no guarda ningún resultado, y tampoco uno que WordPress nunca inicia, así que el último que sí terminó seguía mostrándose como el actual.
• Mejora: el correo electrónico del análisis se envía cuando un análisis encuentra algo nuevo, no después de cada análisis, y su asunto nombra wp-config.php o .htaccess cuando eso es todo lo que ha cambiado.
• Mejora: los eventos de dos factores se pueden filtrar en la auditoría de seguridad, y PHP 8.5 está en la tabla de fin de vida útil de la comprobación de seguridad.
• Corrección: un .htaccess en uploads que solo deniega el acceso ya no se reporta, y tampoco la regla que prohíbe PHP ni una línea comentada. Options +ExecCGI y los manejadores CGI o SSI, que se listaban como reglas personalizadas, ahora son sospechosos.
• Corrección: el archivo index.php de dos líneas que incluye WordPress ya no se reporta como PHP en uploads ni como archivo adicional.
• Corrección: los temas incluidos y Akismet ya no aparecen como archivos del núcleo modificados o faltantes cuando se actualizan o se eliminan.
• Corrección: una cadena hexadecimal de unos 12.000 caracteres o más no era encontrada por la búsqueda de código oculto. Cuanto más largo era el contenido, menos se encontraba.
• Corrección: un nombre de función dividido en trozos no se encontraba cuando una cadena larga de cadenas unidas venía antes en el archivo.
• Corrección: un archivo creado a propósito podía mantener ocupada la búsqueda de código oculto el tiempo suficiente para acortar el análisis.
• Corrección: el análisis de la carpeta de subidas se detenía después de 10.000 archivos sin avisar.
• Corrección: una carpeta que el análisis no podía leer detenía el análisis de uploads, de un plugin o de un tema sin decirlo, y no se comprobaba nada después. Ahora el análisis continúa e informa de la carpeta.
• Corrección: la exploración manual solo guardaba la segunda mitad del análisis en el historial de puntuaciones de la comprobación de seguridad.
• Corrección: la comprobación de seguridad daba por válido un análisis de integridad de archivos que no lo había comprobado todo, siempre que no hubiera encontrado nada en lo que sí comprobó.
• Corrección: la etiqueta Limitar métodos HTTP, y el comentario escrito en .htaccess, describían una regla que no es la que se aplica.
• Corrección: el ajuste de alertas de la auditoría de seguridad decía que un administrador nuevo se registra como crítico. Se registra como advertencia, y tiene su propio correo electrónico en «Usuarios».
• Corrección: el readme describía copias de seguridad automáticas de .htaccess y wp-config.php que ya no existen.
• Corrección: se han eliminado 11 cadenas y un método que nada usaba.

3.0.2

Corrige las direcciones con acentos o letras no latinas en la redirección HTTPS, la comprobación del modo bajo ataque y una dirección de acceso personalizada; evita que el alias www lleve al escritorio, guarda las rutas de integridad de archivos tal y como se han escrito, y evita que la CSP por defecto altere los estilos de los sitios servidos a través de HTTP.

• Corrección: La redirección de HTTP a HTTPS conserva los caracteres codificados en porcentaje de la dirección. Una visita a /categor%C3%ADa/ se redirigió a /categora/, lo que provocaba un error 404, una ruta en cirílico se redirigía a //, y todos los parámetros perdían sus caracteres codificados.
• Corrección: La misma redirección toma el host declarado por el sitio, no de la cabecera «Host». Al visitar el alias «www» del sitio, o el servidor mediante su dirección IP, se enviaba una redirección permanente al escritorio en lugar de a la misma página. Un sitio que servía otros nombres de host propios a través de allowed_redirect_hosts ahora obtiene el host declarado para todos ellos, mientras que el área de administración de un sitio cuyo WordPress se aloja en un host propio permanece en ese host.
• Corrección: Una dirección de acceso oculta escrita en un alfabeto no latino no encontraba nada, así que la página de acceso permanecía oculta y su propia dirección devolvía un error 404. Ahora se compara en mayúsculas y minúsculas, en formato hexadecimal y como UTF-8 sin codificar. Una dirección que solo coincidía tras eliminar sus caracteres codificados, como /my-log%41in/ para /my-login/, ya no abre la página de acceso.
• Corrección: Tras resolver el reto en el modo «Bajo ataque», el visitante accede a la página que ha solicitado, con los acentos y los parámetros intactos.
• Corrección: El registro de actividad conserva la dirección de una solicitud bloqueada tal y como se envió, en lugar de borrar los caracteres codificados.
• Corrección: Ahora funciona la opción de ignorar en «Integridad de archivos» un archivo cuyo nombre contenga caracteres codificados (por ejemplo, un %20 literal) o espacios repetidos. La ruta se guardaba sin esos caracteres, por lo que nunca coincidía con el archivo y la advertencia volvía a aparecer; además, la entrada guardada podía coincidir con otro archivo cuyo nombre estuviera alterado.
• Corrección: Una ruta excluida en «Integridad de archivos» cuyo nombre contenga caracteres codificados (por ejemplo, un %20 literal) o espacios repetidos ahora se guarda tal y como se ha escrito, incluso al exportar e importar los ajustes. Antes se guardaba tras eliminar dichos caracteres, por lo que nunca coincidía. Además, cuando los caracteres codificados formaban parte del final del nombre, se guardaba como la carpeta superior, lo que impedía que se analizara todo el contenido de dicha carpeta. Ahora se omite cualquier línea que contenga etiquetas HTML. Las entradas ya guardadas no se modifican, por lo que aquellas que se guardaron recortadas deben volver a escribirse.
• Corrección: El área de administración y sus URLs abiertas se reconocen a partir de la ruta tal y como se envía. Ya no se interpreta /wp-admin/admin-ajax.php%20 como admin-ajax.php, ni /wp-%41admin/page como una página del área de administración.
• Corrección: En un sitio cuya dirección es http://, la directiva Content-Security-Policy por defecto ya no incluye upgrade-insecure-requests. Con Apache y el módulo de cabeceras activos, esa directiva hacía que los navegadores solicitaran todas las hojas de estilo, scripts e imágenes a través de HTTPS, a lo que el sitio no respondía, por lo que el sitio perdía sus estilos. Ahora la directiva solo se aplica cuando la dirección del sitio es https://, por lo que un sitio servido a través de HTTPS mediante un proxy o una CDN que termine el TLS debería tener su dirección configurada como https://. Las reglas se reescriben al actualizar, por lo que un sitio que ya se viera afectado se recupera al actualizar, y la pestaña «Cabeceras de seguridad» lo indica junto a la política.
• Corrección: El escritorio lee el ajuste de XML-RPC en su ubicación actual. La puntuación de configuración nunca daba los tres puntos por bloquear XML-RPC, y la recomendación de desactivarlo siempre aparecía, ya que ambas se basaban en una casilla de selección que dejó de guardarse a partir de la versión 2.9.7. Un sitio que bloquee XML-RPC, tal y como lo hacen los ajustes predeterminados, verá cómo su puntuación aumenta en dos o tres puntos sin cambiar nada, y la recomendación, cuando sea aplicable, ahora redirige a refuerzo de WP.
• Corrección: La tarjeta «Comprobación de seguridad» del escritorio indicaba que se habían realizado 13 comprobaciones internas, cuando en realidad son 16, y ya no muestra ninguna cifra.

3.0.1

Corrige el problema por el que las listas de perfiles de la identificación en dos pasos, las reglas de contraseñas y la caducidad de las contraseñas volvían a aparecer marcadas tras guardar, y evita que una pestaña guardada borre las listas que no tienen ningún campo visible en pantalla.

• Mejorado: SECURITY.md describe la alerta de autoprotección y el bloque «Integridad de archivos» tal y como funcionan actualmente, y dos comentarios del código que aún describían el comportamiento anterior.
• Corrección: al desmarcar un perfil en «Aplicar a los siguientes perfiles» o en «Perfiles afectados» de la caducidad de contraseñas el cambio se guarda y permanece desmarcado. Las listas de valores se fusionaban posición por posición, tanto al guardar como al leer los ajustes, por lo que una lista más corta que la original volvía a aparecer con el final de esta última añadido, y no era posible eliminar ningún perfil.
• Corrección: ya no se introduce un 0 literal en las listas cuando se desmarca el primer perfil de un grupo.
• Corrección: al desmarcar todos los perfiles de un grupo ahora se envía una lista vacía en lugar de no enviarse nada, para que se pueda distinguir de un formulario que nunca haya incluido ese campo.
• Corrección: al guardar una pestaña ya no se vacía una lista que no tenga ningún campo en esa pantalla, como los métodos HTTP permitidos del cortafuegos o la lista de nombres de usuario no seguros. Esos valores se conservaban únicamente porque, al leer los ajustes los valores originales volvían a aparecer como primeros en la lista.
• Corrección: la autoprotección toma un manifiesto que WordPress.org confirma para la versión instalada, en lugar de indicarla como sustituida definitivamente. Un sitio que había instalado una copia de prueba de una versión y, posteriormente, la versión publicada, seguía en estado crítico, y la reparación no podía solucionarlo, ya que reinstala esos mismos archivos oficiales.
• Corrección: las listas que no tenían ningún campo en ninguna pantalla vuelven a aparecer tras la actualización. Al guardar una pestaña, estas quedaban vacías en la base de datos, y hasta ahora esto quedaba oculto porque la configuración volvía a los valores iniciales al leerse. De lo contrario, un sitio que hubiera guardado la pestaña «Cortafuegos» habría empezado a devolver un error 403 para todos los métodos HTTP. Los cuatro elementos son los métodos HTTP permitidos, los nombres de usuario no seguros, los roles de aprobación de registros y los puntos finales REST públicos, y cada uno de ellos vuelve a su valor original, por lo que una lista que se haya acortado a propósito no se ve afectada.
• Corrección: los cuatro parámetros también vuelven a su valor inicial cuando la lista almacenada está vacía, independientemente del origen de dicha lista. Ninguno de ellos puede vaciarse desde ninguna pantalla, por lo que una lista vacía es un vestigio, y solía significar bloquear todos los métodos, permitir todos los registros aunque el conmutador indicara lo contrario, o desactivar la API REST pública.
• Corrección: adopción de un manifiesto que, tras la confirmación de WordPress.org, se registra tal y como es, en lugar de como un cambio de versión que no se produjo.

3.0.0

Ahora Vigilant verifica sus propios archivos comparándolos con WordPress.org, un manifiesto SHA-256 incluido y una huella digital de la base de datos. Se revisa a sí mismo tras cada actualización y restaura sus propias tareas programadas. La puntuación de la comprobación de seguridad puede variar ligeramente: se ha añadido una nueva comprobación.

• Nuevo: Autoprotección. Vigilante verifica sus propios archivos comparándolos con tres referencias: las sumas de comprobación SHA-256 que WordPress.org publica para la versión instalada, un archivo MANIFEST.sha256 incluido en el plugin y una huella digital de ese manifiesto almacenada en la base de datos. La comprobación se ejecuta primero en cada análisis de integridad de archivos, fuera del tiempo asignado al análisis y sin tener en cuenta las rutas y extensiones excluidas del mismo, y una vez al día si no se ha realizado ninguna otra comprobación en las últimas 24 horas. Informa de archivos modificados, que faltan, ilegibles o añadidos, carpetas que no se pueden listar, enlaces simbólicos, archivos que figuran en el manifiesto pero que WordPress.org no distribuye, y un manifiesto sustituido, borrado o no válido. Un archivo PHP o JavaScript modificado, o un archivo de datos que cargue el plugin, es crítico, al igual que un archivo añadido que un servidor web pueda ejecutar, independientemente de la extensión de su nombre. Una hoja de estilo o una imagen modificada supone una advertencia, ya que los plugins de optimización y los servidores suelen reescribirlos, y los archivos de texto cuyos finales de línea haya reescrito el servidor no se notifican, ni tampoco el manifiesto cuando se haya reescrito de esa forma. «Integridad de archivos» muestra el resultado en el primer bloque de los resultados del análisis, con la explicación de lo que significa cada hallazgo y cómo solucionarlo. No hay ninguna opción para desactivarla: un plugin de seguridad al que se le pueda indicar que no se compruebe a sí mismo tiene una opción cuya única usuaria real es quien acaba de modificar sus archivos.
• Nuevo: Vigilant se comprueba a sí mismo al final de cada actualización que WordPress le aplica, incluida una actualización realizada mediante la subida de un archivo zip, una vez que se ha restaurado la copia anterior tras una actualización fallida, y detecta un cambio de versión realizado fuera del actualizador, como una subida manual o por FTP, en la siguiente página de administración que abra un administrador o en la tarea de mantenimiento diario. Una nueva versión que WordPress.org no pueda confirmar genera una advertencia en lugar de considerarse fiable, la huella digital no se vuelve a tomar cuando se reactiva el plugin y, siempre que se detecte una degradación de versión, se notifica por correo electrónico.
• Nuevo: La autoprotección cuenta con su propia alerta y no hay ningún ajuste que permita desactivarla. Un hallazgo crítico relacionado con los archivos propios de Vigilante siempre envía un correo electrónico, independientemente de dónde se detecte; este se deduplica según el conjunto de hallazgos y se envía una sola vez en la red, desde el sitio al que pertenecen los archivos compartidos y siempre también a la dirección de correo electrónico de la administración de la red. Ya no se incluye en el correo electrónico del análisis de integridad de archivos, que se rige por una configuración de notificaciones: desactivar el informe sobre archivos modificados también desactivaba la alarma sobre el propio plugin. Las advertencias permanecen en pantalla, donde no incitan a nadie a ignorar un correo electrónico, salvo en el caso de descenso o cambio de versión que no se pueda verificar con WordPress.org, que siempre se envían. Tampoco hay recordatorios: cada conjunto distinto de hallazgos solo se avisa una vez.
• Nuevo: No se puede desactivar la autoprotección. No hay ningún ajuste para ello, por lo que la única forma es mediante el filtro vigilante_self_integrity_enabled, y Vigilante lo señala como crítico en todas las pantallas de administración, indica los nombres de los archivos que lo interceptan y lo registra en la auditoría de seguridad. El código que elimina las interceptaciones de la comprobación se detecta al final de cada página de administración y se notifica de la misma manera, junto con los plugins que se cargaron en esa solicitud. Además, un resultado con más de tres días de antigüedad deja de considerarse verificado, independientemente de lo que haya detenido la comprobación, por lo que un estado «verde» antiguo nunca se muestra como si fuera actual.
• Nuevo: Supervisión de tareas programadas. Si algo elimina el mantenimiento diario, las comprobaciones por hora, la comprobación de seguridad semanal, la comprobación de plugins desactivados o el análisis de integridad programado, Vigilante lo vuelve a programar y lo registra, y si esa misma tarea vuelve a eliminarse en un plazo de 30 días, se informa de ello como un problema crítico por correo electrónico. Las tareas que hayas desactivado no se ven afectadas. En los sitios activados antes de que existiera alguna de esas tareas, la primera pasada las programa una vez, sin informar de ello. En una red multisitio, supervisa el sitio principal.
• Nuevo: La comprobación de seguridad incluye una prueba de autoprotección de Vigilante en la categoría «Interna», la comprobación individual más exigente del analizador, cuya puntuación ahora se calcula sobre 40 en lugar de 30. Aunque los propios archivos de Vigilante aparecen como modificados, ambas puntuaciones del plugin se mantienen en la parte inferior de la escala y explican el motivo: todos los demás resultados se generan a partir de ese mismo código. El informe guardado se borra al actualizar, por lo que la puntuación puede variar tras la siguiente comprobación.
• Nuevo: La autoprotección cuenta con su propio bloque en «Integridad de archivos», el primero de los resultados, codificado por colores según la gravedad, con los archivos detectados, el significado de cada hallazgo y las medidas que hay que tomar al respecto. El mismo texto aparece en los detalles de la «Comprobación de seguridad», en los detalles de cada entrada de la «Auditoría de seguridad» y en el correo electrónico de alerta, por lo que los cinco elementos nunca muestran información contradictoria. Los cambios en los propios archivos de Vigilante también se indican en rojo en el menú de Vigilante, se resumen en la parte superior de su escritorio y se muestran en todas las pantallas de administración hasta que se solucionen. Además, se muestra una advertencia en las pantallas de Vigilante. Los hallazgos sobre los propios archivos de Vigilante ya no aparecen en la lista junto con el resto del análisis, y no se pueden ignorar.
• Nuevo: Reparación con un solo clic. Cuando Vigilante detecta que sus propios archivos han sido modificados, puede descargar una copia limpia desde WordPress.org y sustituir únicamente los archivos del plugin, conservando tus ajustes, tablas y registros, tras mostrar una pantalla en la que se explica exactamente lo que va a hacer. Instala la versión que distribuye WordPress.org, nunca la versión que indican los archivos, y nunca una versión más antigua que la que este sitio haya verificado. En una red se requiere un superadministrador, y cuando WordPress no puede modificar los archivos del plugin, la pantalla indica los pasos que hay que seguir manualmente.
• Nuevo: SECURITY.md, con instrucciones sobre cómo informar de una vulnerabilidad, qué cubre y qué no cubre la autoprotección, y cómo verificar tú mismo una instalación, y bin/verify-manifest.php, una herramienta de línea de comandos que comprueba la carpeta del plugin con respecto al manifiesto y el manifiesto con respecto a WordPress.org.
• Mejorado: «Integridad de archivos» ya no analiza Vigilante como un plugin normal, por lo que sus archivos no se incluyen dos veces en el informe; además, al actualizar, los propios archivos de Vigilante se eliminan de la lista de ignorados, donde podrían desactivar la nueva comprobación.
• Mejorado: En una red multisitio ningún usuario puede ignorar en ningún sitio un hallazgo relacionado con los archivos propios de Vigilant. Si se borran los resultados del análisis sin disponer de derechos de red, dicho hallazgo se mantiene y la alerta correspondiente también se envía al correo electrónico de la administración de la red.

Para entradas anteriores del registro de cambios revisa el archivo changelog.txt.