Wordfence trae loginSec_disableApplicationPasswords=1 de fabrica. Con eso
wp_is_application_passwords_available() devuelve false, la seccion desaparece
del perfil sin dar ni un aviso, y la autenticacion por REST responde 401. Los
bots de la carta publican asi (publicabot, de icalvotorre), o sea que estaban
sin poder publicar y la carta 738 se compone manana.
Lo introdujimos nosotros: en produccion Wordfence no estaba instalado, se
anadio el 31-jul. No salio en el ensayo porque probamos lectura de la REST API
pero nunca autenticacion. Lo detecto Inma; la traza es un 401 real suyo contra
/wp-json/wp/v2/users/me a las 11:14 UTC.
Aplicado en produccion y comprobado con su prueba de humo: POST a
/wp-json/wp/v2/posts devuelve 201, y el ultimo uso de publicabot pasa de 29-jul
a hoy.
Se anade como paso 3e y no como arreglo de una vez porque el paso 3d reinstala
Wordfence si falta, y una instalacion nueva vuelve a ponerlo a 1.
Dos detalles del propio script, que fallaban en silencio:
- va por heredoc y no por la funcion wp(), porque esa expande "$*" y se come
las comillas del codigo PHP.
- y sin --skip-plugins, o la clase wfConfig de Wordfence no existe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aviso de Mixbot (2-ago): los bots de la carta publican por wp-nuevo.feadulta.com,
no por www, porque el WAF de Cloudflare los bloquea por www (regla "bloquear bots
1"). Ese hostname no tiene registro propio, lo cubre el wildcard, y Traefik solo
enruta nuevo.feadulta.com: al mover el A del apex los bots dejarian de publicar.
La carta 738 se compone el martes.
Se anade el paso 0 al runbook. Hay que hacerlo en el PANEL: por API el PATCH de
fqdn da 422 y actualizar SERVICE_FQDN_WORDPRESS cambia la variable pero no
regenera los routers (comprobado hoy). Plan B documentado: los bots pueden pasar
a nuevo.feadulta.com, que es grey cloud y por tanto no pasa por Cloudflare ni le
aplica ninguna regla del WAF.
Decision de Rafa: el bloqueo de login lo lleva Wordfence y sale
limit-login-attempts-reloaded. Wordfence hace lo mismo y ademas firewall de
aplicacion, escaner de malware y 2FA; los dos juntos son dos contadores
compitiendo. Retirado del staging (7 plugins activos, sitio en pie) y anadido al
post-import-seguridad.sh (paso 3c) porque el dump lo revive en cada import, junto
con sus 12 opciones huerfanas. Nuevo paso 3d que verifica que Wordfence sigue
activo y lo reinstala si faltara.
Inma confirma que el modo SSL de la zona es Full, no Flexible: cae el riesgo de
bucle de redireccion. Marcado como resuelto en los verdes previos.
Anadida la seccion del correo: el cutover no lo toca (MX a otra IP), pero la
caducidad del 07/08 si, y ediciones@/contenido@ son de donde sale la carta.
Anotado tambien que Cloudflare devuelve 403 a la IP de Rafa para cualquier
hostname de feadulta: un 403 desde su maquina no prueba nada, la verificacion de
los bots la tienen que hacer ellos.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Buscando si Wordfence habia que reinstalarlo limpio (#183 comment-492) resulta
que Wordfence NO esta instalado en produccion. Lo que si queda es una opcion
llamada 'wordfence_core_options' que no es suya: es el payload del atacante,
disfrazado con ese nombre para pasar por legitimo.
Cifrado con un cesar de una letra (ejw->div, tuzmf->style, isfg->href). Una vez
descifrado:
<div style="position: absolute;margin-top: -110px;">
<div style="position: absolute; left: -7585px;">
<a href="https://1xbetjap.com/ja/casino/">
Un div fuera de pantalla con enlaces a un casino japones, con el campo output
apuntando a wp_footer. Esto explica los "dos POST a wp-admin/options.php" del
comment-492, que se habian atribuido a que el atacante toco la configuracion de
Wordfence: lo que hacia era crear esta opcion.
Hoy esta inerte porque quien la leia era el plugin wp-highlits, en cuarentena.
Pero viaja dentro del dump, asi que CADA import la reintroduce en el servidor
nuevo: por eso va aqui y no como limpieza manual de una vez.
Se preserva el valor en /data/feadulta-migracion/evidencia-183/ antes de borrar.
Barrido de la BD del destino: es la unica. 0 en post_content, 0 enlaces ocultos
fuera de pantalla en el contenido, 0 referencias a las IPs del atacante.
Nota sobre el escaneo previo del dump: lo di por limpio buscando <script, eval(,
base64_decode y gzinflate. Este payload no lleva ninguno de esos patrones y paso
el filtro. El escaneo por firmas conocidas no acredita limpieza.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Con los tiempos REALES medidos en el ensayo del 31-jul, no estimados:
dump 25s + subida 74s + saneo 2s + import 107s = camino critico ~3min30s.
- docs/cutover/RUNBOOK-cutover-wordpress.md: los pasos en orden, copiables, con
el rollback y los tres verdes obligatorios previos (freeze, CDMON vivo, modo
SSL de la zona).
- scripts/cutover/post-import-seguridad.sh: rota la contrasena de los 6
administradores (las lee del .env del perfil, nunca van en el repo), retira el
rol a pabloarias/josek/andrey y limpia los cron huerfanos de Yoast y WP
Profile Builder. Es un script y no una tarea manual porque el dump revive esas
cuentas en CADA import.
- tools/e2e/sites/nuevo.json: la suite toma el host de un JSON, asi que apuntarla
al staging es anadir un fichero.
Hallazgo del ensayo: el origen es MariaDB 11.8.6 y el destino MySQL 8.4.10; el
dump trae 20 tablas con collations uca1400_* que MySQL rechaza. El saneo las
mapea antes de importar. Sin ese paso, el import aborta.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rafa