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

Historial de cambios

3.0.4

Fixes the expired password notice, which was missing when the password expired during an open session, lands the user at the top of the profile where the notice is, fixes a redirect loop for WooCommerce customers, and limits an account with an expired password to its own profile form.

• Improved: when a password has expired, the user is taken to the top of their profile, where the notice says why, instead of straight to the password field with the notice out of sight above it. The notice now has a link to the field.
• Fix: the notice that a password has expired was missing when it expired while the user was still logged in. The user was sent to the profile with no explanation, and the notice only appeared after logging in again.
• Fix: on the last day before a password expires the warning notice was not shown, so the forced change arrived with no warning the day before.
• Fix: in a WooCommerce store, an account with no access to the admin area, a customer for example, whose role is in Affected Roles was caught in a redirect loop when its password expired. WooCommerce sent it from the profile to My Account and Vigilant sent it back, so it could neither use the store nor change the password. That account is now let into its profile screen in the admin area while the change is pending, and only into that screen. The password is changed there, not in My Account, and once it is saved WooCommerce takes the account back to My Account as usual.
• Fix: while a password change was pending, every request to the profile screen was let through, and that screen can be asked for other things: a plugin page, an importer, an action passed in the address, or the profile of another user for an account allowed to edit users. An account with an expired password could go on using those. Only its own profile form is let through now, to be shown or to be saved. On a network, the profile screens of the network admin and of the user dashboard lead to the profile of the site, where the notice is.
• Fix: on a site whose WordPress Address and Site Address are on different hosts, a headless site for example, or whose address has accented or non-Latin letters saved as written, a user with an expired password was caught in a redirect loop. The redirect to the profile came out as a redirect to the dashboard, which sent the user to the profile again. It now reaches the profile.

3.0.3

File Integrity now compares themes with their WordPress.org package, searches all the code that has no official copy, and looks at must-use plugins, drop-ins, wp-admin, wp-includes and the rest of wp-content. Scan emails are sent once per new finding.

• Improved: File Integrity compares themes from WordPress.org with the package WordPress.org publishes for the installed version. WordPress.org has no checksums for themes, so until now no theme file was compared with anything. The package is downloaded once per version.
• Improved: File Integrity searches every PHP file of a plugin or theme with no official copy for hidden code, not only the first 50, and reads files of up to 8 MB. A file over 512,000 bytes was not opened, so it passed as clean. One over 8 MB is listed as not searched.
• Improved: File Integrity looks at files added to wp-admin and wp-includes, at must-use plugins and drop-ins, at loose PHP files in wp-content, and at folders with PHP among the plugins or the themes that WordPress does not list as one.
• Improved: File Integrity searches the PHP files of the other folders of wp-content (languages, upgrade and the like) for hidden code. A translation file that holds anything other than text is reported, because WordPress loads translation files on every request.
• Improved: a new installation no longer starts with wp-content/cache among the excluded paths, so that folder is searched too. A site that already has it there keeps it.
• Improved: File Integrity reports a .htaccess, .user.ini or php.ini outside uploads that makes the server run code or load a file.
• Improved: File Integrity finds, in code with no official copy, request data run as code or as a command, a function chosen by the request and a file included from another server. The same text in a comment is not reported.
• Improved: a file on which the search for hidden code cannot finish is listed as not searched instead of passing as clean.
• Improved: File Integrity now compares wp-includes/version.php, and compares sites that are not in English with the English checksums while WordPress.org has none for their language, instead of leaving the core unchecked.
• Improved: File Integrity reports files deleted from a plugin or a theme, and reports a failed request to WordPress.org as an error instead of treating the plugin as one with no official copy.
• Improved: File Integrity reports more file types in uploads (.pht, .php8, names such as shell.php.suspected, .user.ini, php.ini, shell and CGI scripts), a .user.ini or php.ini in the site root that loads a file on every request, and backups left in the site root.
• Improved: the File Integrity tab says what each kind of finding usually is and what to do about it, names the plugins and themes that could not be compared, and says when a scan was partial instead of saying that every file passed.
• Improved: when a scan runs out of time, File Integrity and the scan email name the plugins, the themes and the areas it did not reach, and File Integrity lists the folders to exclude so that a scan run by hand reaches the rest. A scan runs for 60 seconds at most and starts from the beginning each time, so on a very large site the same part is left unchecked on every scan.
• Improved: File Integrity and Security Check say when Excluded Paths holds the whole folder of a plugin or of a theme, or the uploads folder. No scan looks inside them, and Security Check no longer counts such a scan as clean.
• Improved: File Integrity and Security Check say when no scheduled scan has finished for longer than the schedule allows. A scan the server stops halfway stores no result, and neither does one WordPress never starts, so the last one that did finish kept showing as the current one.
• Improved: the scan email is sent when a scan finds something new, not after every scan, and its subject names wp-config.php or .htaccess when that is all that changed.
• Improved: two-factor events can be filtered in Security Audit, and PHP 8.5 is in the end-of-life table of Security Check.
• Fix: a .htaccess in uploads that only denies access is no longer reported, and neither is the rule that forbids PHP or a commented line. Options +ExecCGI and CGI or SSI handlers, which were listed as custom rules, are now suspicious.
• Fix: the two-line index.php placeholder WordPress ships is no longer reported as PHP in uploads or as an extra file.
• Fix: the bundled themes and Akismet no longer show as modified or missing core files when they update or are deleted.
• Fix: a hexadecimal string of some 12,000 characters or more was not found by the search for hidden code. The longer the payload, the less it was found.
• Fix: a function name split in pieces was not found when a long chain of joined strings came before it in the file.
• Fix: a file built for the purpose could keep the search for hidden code busy long enough to cut the scan short.
• Fix: the scan of uploads stopped after 10,000 files without saying so.
• Fix: a folder the scan could not read stopped the scan of uploads, of a plugin or of a theme without saying so, and nothing after it was checked. The scan now goes on and reports the folder.
• Fix: Scan now stored only the second half of the scan in the score history of Security Check.
• Fix: Security Check passed a file integrity scan that had not checked everything, as long as it had found nothing in what it did check.
• Fix: the Limit HTTP Methods label, and the comment written to .htaccess, described a rule that is not the one applied.
• Fix: the alert setting of Security Audit said a new administrator is logged as Critical. It is logged as Warning, and has its own email in Users.
• Fix: the readme described automatic backups of .htaccess and wp-config.php that no longer exist.
• Fix: removed 11 strings and a method that nothing used.

3.0.2

Fixes addresses with accents or non-Latin letters in the HTTPS redirect, the Under Attack check and a custom login address, stops the www alias landing on the dashboard, saves File Integrity paths as written, and stops the default CSP from breaking the styles of sites served over http.

• Fix: the HTTP to HTTPS redirect keeps the percent-encoded characters of the address. A visit to /categor%C3%ADa/ was sent to /categora/, a 404, a path in Cyrillic to //, and every parameter lost its encoded characters.
• Fix: the same redirect takes its host from the one the site declares, not from the Host header. A visit to the www alias of the site, or to the server by its IP, was sent with a permanent redirect to the dashboard instead of the same page. A site that served other hostnames of its own through allowed_redirect_hosts now gets the declared host for all of them, while the admin area of a site whose WordPress lives on a host of its own stays on that host.
• Fix: a hidden login address written in a non-Latin script matched nothing, so the login page was hidden and its own address answered 404. It now matches in upper and lower case hex and as raw UTF-8. An address that only matched after its encoded characters were deleted, such as /my-log%41in/ for /my-login/, no longer opens the login page.
• Fix: after solving the Under Attack challenge the visitor lands on the page they asked for, with its accents and parameters intact.
• Fix: the activity log keeps the address of a blocked request as it was sent, instead of with its encoded characters deleted.
• Fix: ignoring a file in File Integrity whose name has encoded characters (a literal %20, for example) or repeated spaces now works. The path was saved with those characters deleted, so it never matched the file and the warning came back, and the saved entry could match a different file with the mangled name.
• Fix: an excluded path in File Integrity whose name has encoded characters (a literal %20, for example) or repeated spaces is now saved as written, also when exporting and importing the settings. It was saved with them deleted, so it never matched, and when the encoded characters were the last part of the name it was saved as the folder above it, which silenced the scan of everything inside that folder. A line with HTML tags is now dropped. Entries already saved are not changed, so one that was saved cut has to be written again.
• Fix: the admin area and its open endpoints are recognised from the path as sent. /wp-admin/admin-ajax.php%20 is no longer taken for admin-ajax.php, nor /wp-%41admin/page for a page of the admin area.
• Fix: on a site whose address is http://, the default Content-Security-Policy no longer includes upgrade-insecure-requests. With Apache and the headers module active, that directive made browsers ask for every stylesheet, script and image over https, where the site does not answer, so the site lost its styles. The directive is now written only when the site address is https://, so a site served over https through a proxy or CDN that terminates TLS should have its site address set to https://. The rules are rewritten on update, so a site that was already affected recovers by updating, and the Security Headers tab says so next to the policy.
• Fix: the Dashboard reads the XML-RPC setting where it lives now. The Configuration Score never gave the three points for blocking XML-RPC, and the recommendation to disable it always showed, because both read a checkbox that stopped being saved in 2.9.7. A site that blocks XML-RPC, as the factory settings do, will see its score go up by two or three points without changing anything, and the recommendation, when it applies, now leads to WP Hardening.
• Fix: the Security Check card on the Dashboard said it ran 13 internal checks when there are 16, and no longer gives a number.

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 agregado, 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 agregado 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 agregados, 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 agregado 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.