Migración, Modernización y Seguridad

• Se identificó y eliminó un total de 6 puertas traseras e implantes distintos que le daban al atacante acceso remoto y persistencia, incluidos mecanismos que se reinstalaban solos si se los borraba a medias.
• Se removió el mecanismo de encubrimiento de spam hacia los buscadores. Se verificó que quedó en cero: 0 de 59 sitios seguían sirviendo ese contenido tras la limpieza.
• Se analizaron cerca de 3,69 millones de archivos en ambos servidores viejos; de todo ese universo solo existían 2 infecciones reales, y ambas fueron limpiadas.
• Se retiraron los archivos que el atacante había plantado para intentar reclamar la propiedad de varios dominios ante Google.
• Se adoptó una reconstrucción limpia: cada sitio se levantó sobre una instalación nueva, con temas y complementos de fuentes oficiales, importando únicamente la base de datos verificada y el contenido ya revisado. Nada del entorno comprometido viajó a la plataforma nueva.
• El servidor viejo comprometido fue apagado y se confirmó que ya no atiende tráfico.
• Las cuentas administrativas se depuraron y quedaron solo las legítimas.
• Los re-análisis de seguridad sobre la plataforma nueva dan limpio hoy; un elemento marcado por una herramienta resultó ser un falso positivo (un componente legítimo del propio WordPress).

• Todo el tráfico web público entra ahora obligatoriamente por la red de seguridad de Cloudflare (con su protección contra ataques y abusos). El servidor ya no es accesible de forma directa: los intentos de saltarse esa protección quedan bloqueados.
• El acceso administrativo se sacó de internet público y se protegió detrás de un control que solo permite a las personas autorizadas.
• Se establecieron 3 vías de acceso independientes y redundantes para el equipo técnico, con protecciones automáticas para evitar cualquier bloqueo accidental.
• Se verificó en vivo que los sitios cargan correctamente por el camino seguro y que el acceso directo quedó cerrado.

• Se consolidaron los dos servidores viejos en una sola plataforma nueva, complementada con una red de distribución global (CDN) para los sitios estáticos y un espacio dedicado para las aplicaciones más pesadas.
• Se reconcilió el inventario completo —que se creía de unos 64 sitios— hasta un mapa autoritativo de 84 dominios, cada uno con su estrategia definida.
• Se determinó, sitio por sitio, dónde estaba la versión viva y más reciente, para no migrar nunca una copia vieja y perder trabajo del cliente.
• Se corrigieron los errores de configuración heredados que dejaban sitios caídos.
• Se verificó que todos los sitios activos ya no dependen de los servidores viejos. El resultado fue cero fallas atribuibles al servidor: lo que hoy no está en línea corresponde a decisiones o trámites de dominio del lado del cliente.

Cada sitio se ubicó en el modelo que mejor le conviene:

• Se preservaron los paneles de edición privados de todos los sitios estáticos, protegidos con control de acceso, para que el cliente nunca pierda la capacidad de editar.
• Se demostró que cambiar de un modelo a otro es sencillo: algunos sitios pasaron de estático a dinámico (para autoedición) y otros de dinámico a estático (cuando no requerían funciones en vivo).
• Se reconstruyó por completo el motor de generación estática para que entienda el JavaScript moderno. Antes, los sitios hechos con constructores visuales perdían sus elementos interactivos (contadores, carruseles, animaciones). El nuevo motor carga cada página como un navegador real y captura todo: 21 sitios regenerados, 1.511 páginas y 8.790 recursos, con 19 de 19 sitios pasando la prueba de calidad y cero errores de carga. Los videos de portada demasiado grandes se comprimen automáticamente.

• Un botón de "Publicar" con barra de progreso en vivo dentro del panel de cada sitio estático. El cliente edita, pulsa Publicar, y el sistema regenera el sitio y lo pone en línea automáticamente.
• La publicación es fiel: respeta los elementos interactivos, los sitios en varios idiomas y los videos (que se comprimen solos). Se validó por el mismo camino que usa el cliente, con resultados impecables.
• Se desplegó la herramienta en los sitios estáticos del cliente.
• Publicación incremental: el sistema regenera solo lo que cambió. En un sitio de ~500 páginas, esto bajó el tiempo de publicación de ~50 minutos a ~6,5 minutos.

• Se conectaron 54 de 54 sitios WordPress administrables al panel central (inventario, actualizaciones, sincronización y mantenimiento).
• Los sitios cuyo dominio público está temporalmente inactivo por trámites de registrador siguen siendo administrables desde el panel, de modo que el mantenimiento no se detiene.

• Se realizó una auditoría completa de todos los formularios de contacto (91 formularios en los sitios dinámicos, más los de los estáticos), documentando destinatario, campos y estado.
• Se reactivaron los formularios de los sitios estáticos apuntándolos a un servicio de envío confiable, con el destinatario real de cada negocio; varios ya quedaron en vivo y verificados.
• Se corrigió un formulario que guardaba mensajes pero nunca notificaba a nadie.
• Se acordó con el cliente la política de destinatarios (a qué correo llega cada formulario).
• Se dejó señalado, como acción recomendada, unificar un servicio de correo confiable para los sitios dinámicos, de modo que todos sus formularios entreguen sin falta.

• Con solo escribir el nombre del dominio, la herramienta crea el sitio, su panel de edición, instala la herramienta de publicación, prepara el dominio y la red de distribución, configura el acceso, hace la primera publicación y deja el sitio listo — mostrando el avance paso a paso.
• Se probó de punta a punta con un dominio nuevo real, que quedó en línea correctamente.

• Se rescataron 11 o más bases de datos del servidor viejo apagado, de forma segura (sin volver a encender el sistema comprometido), y se reconstruyeron en la plataforma nueva. Sitios que de otro modo se habrían perdido, se recuperaron.
• Un sitio se reconstruyó a partir de un respaldo en disco cuando ya no existía su base de datos en ningún lado.
• Se resolvió un incidente de contaminación: una restauración de un respaldo viejo por parte del equipo introdujo miles de enlaces rotos en un sitio; se limpió por completo y se verificó que quedó impecable, conservando la evidencia en cuarentena.
• Cada cambio de riesgo se hizo con copia de seguridad y posibilidad de reversa inmediata.
• Se documentó con honestidad lo que no se pudo recuperar: 3 bases de datos perdidas y 12 dominios sin contenido recuperable, para que el cliente decida.

• Se consolidaron cerca de 57–58 dominios en una sola cuenta de Cloudflare para administración central.
• El paso de cada sitio a la nueva plataforma se hizo de forma controlada y reversible, y —punto clave— sin interrumpir el correo de ningún cliente en ningún momento.
• Todos los sitios cuentan con certificado de seguridad (HTTPS) válido, y se forzó la navegación segura.
• Se aclaró el mito del "malware japonés": en varios casos eran dominios vencidos secuestrados por terceros, con el contenido real intacto. La solución no es "limpiar", sino recuperar o renovar el dominio.
• El rendimiento mejoró de forma notable: los sitios estáticos se sirven desde la red global de Cloudflare, la publicación es más rápida y los recursos pesados se optimizan solos.