Seguridad de WordPress en varios sitios: actualizar a tiempo y quitar lo abandonado

Cuando administras entre 5 y 30 sitios de clientes, la seguridad de WordPress deja de ser una decisión que se toma una vez, como instalar un plugin o elegir una contraseña.
Pasa a ser un trabajo de mantenimiento que se repite: actualizar a tiempo, quitar lo que ya nadie mantiene, saber quién tiene acceso a cada sitio y contar con copias que se puedan restaurar.

Esa es la idea de esta guía.
No existe un plugin mágico que deje todos tus sitios «seguros»: la documentación oficial de WordPress sobre seguridad lo plantea como reducir riesgos y planificar la recuperación, y pone en primer lugar mantener al día WordPress, los plugins y los temas.
Aquí lo bajamos a la práctica de quien lleva varios sitios, con foco en el «antes de actualizar» y en los plugins abandonados.

Por dónde suelen entrar los problemas en WordPress

La documentación oficial no ofrece un ranking de causas, pero sí señala los puntos que conviene vigilar:

• Software desactualizado.
  La tecnología obsoleta puede tener errores o vulnerabilidades que ponen el sitio en riesgo.
  Las versiones antiguas de WordPress no reciben actualizaciones de seguridad, y cuando se corrige una vulnerabilidad, la información para aprovecharla es casi con seguridad pública.
• Plugins y temas sin mantenimiento.
  La documentación recomienda elegir los que reciben actualizaciones de forma activa, y borrar del sistema los que no se usan.
• Origen dudoso.
  No se recomienda obtener plugins o temas fuera del repositorio de WordPress.org o de empresas conocidas.
• Credenciales y usuarios.
  Quien entra en una cuenta de administrador puede instalar scripts maliciosos y comprometer potencialmente todo el servidor.
  Los ataques de fuerza bruta, que prueban combinaciones de usuario y contraseña de forma automática, apuntan a esa puerta.

Cómo detectar un plugin o tema abandonado

Un plugin abandonado sigue instalado y funcionando, pero su autor ya no lo mantiene.
Estas son las señales que puedes comprobar:

• El aviso del directorio de WordPress.org.
  En la ficha de un plugin que lleva mucho sin actualizarse, el directorio muestra un aviso que, traducido, dice que el plugin no se ha probado con las últimas 3 versiones principales de WordPress, que puede que ya no tenga mantenimiento ni soporte y que podría tener problemas de compatibilidad.
  Habla de mantenimiento y compatibilidad: no dice que exista una vulnerabilidad concreta, ni que no exista.
• La fecha de «Última actualización».
  La ficha de cada plugin en el directorio la muestra, junto con su registro de cambios.
• El aviso dentro del wp-admin.
  Al añadir plugins, cada uno indica si es compatible con tu versión de WordPress o si no se ha probado con ella.
  Según la documentación, si un plugin no se ha actualizado desde la última versión del núcleo, puede ser incompatible o su compatibilidad puede ser desconocida.
• Plugins de pago o de fuera del directorio.
  No muestran ese aviso, así que conviene mirar el registro de cambios del proveedor y comprobar que la licencia sigue vigente.
  Es criterio de quien escribe, no de la documentación.

Si confirmas que un plugin está abandonado, sustitúyelo por otro que sí se mantenga o prescinde de su función, y elimínalo.
El procedimiento del wp-admin es desactivarlo y, una vez desactivado, usar su enlace para borrarlo: dejarlo desactivado no es quitarlo del sistema.
Como criterio, lo mismo aplica a los temas que ya no se usan en ningún sitio.

Qué revisar antes de actualizar

Actualizar es lo que más protege y, a la vez, el momento de mayor riesgo del mantenimiento.
Conviene hacerlo con un orden fijo:

1. Copia previa.
   La documentación indica hacer una copia del sitio antes de actualizar, para poder restaurarlo si algo falla.
   Ya explicamos cómo hacerla y comprobarla en la guía de copias de seguridad de WordPress.
2. Registro de cambios.
   La documentación recomienda revisar los plugins antes de actualizarlos en bloque.
   Fíjate en si la versión corrige un fallo de seguridad o cambia algo importante.
   Cuanto más urgente es la corrección, menos conviene esperar: es criterio de quien escribe.
3. Compatibilidad.
   Mira el aviso de compatibilidad que muestra el wp-admin.
   Si vas a saltar varias versiones del núcleo, la documentación remite a sus instrucciones ampliadas en lugar del método rápido.
4. Probar primero.
   Es criterio propio: si una actualización afecta a varios sitios, aplícala antes en un entorno de pruebas o en el sitio menos crítico, y sigue con el resto solo si todo funciona.
5. Orden.
   Como criterio, actualiza primero el núcleo, luego los plugins y al final el tema, comprobando el sitio entre paso y paso para saber qué cambio causó un problema.
6. Comprobación final.
   Abre la portada, un formulario y el inicio de sesión, y si hay tienda, haz un pedido de prueba.
   También es criterio propio.

Sobre las actualizaciones automáticas: desde WordPress 3.7, la mayoría de los sitios aplican solas las actualizaciones menores y de seguridad del núcleo, y las versiones principales requieren pulsar el botón.
Desde WordPress 5.5, las de los plugins se pueden activar plugin por plugin.
Cuanto más crítico es el sitio, más sentido tiene revisar a mano: es una decisión de criterio.

Accesos y usuarios: contraseñas, 2FA y roles mínimos

Muchos incidentes empiezan por un acceso legítimo que nadie debería seguir teniendo.

• Contraseñas.
  La documentación pide contraseñas fuertes y difíciles de adivinar, y recomienda evitar el nombre propio, el de la empresa o el del sitio, las palabras de diccionario y las contraseñas cortas o solo numéricas.
  También aconseja evitar usuarios fáciles de adivinar como admin.
  Para varios sitios, la guía sobre fuerza bruta recomienda contraseñas únicas con un gestor de contraseñas.
• Autenticación en dos pasos (2FA).
  La documentación recomienda activarla, y la guía sobre fuerza bruta la pide para todos los administradores y usuarios con privilegios.
  WordPress no la incluye en el núcleo: hay que añadirla con un plugin o con un sistema de inicio de sesión único.
  Si alguien pierde el dispositivo del segundo paso, puede quedarse fuera del sitio, así que conviene definir antes un método de recuperación (criterio propio).
• Roles mínimos.
  WordPress trae seis roles predefinidos, que definen las responsabilidades del usuario en el sitio.
  El administrador accede a todas las funciones del sitio, el editor publica y gestiona entradas, incluidas las de otros usuarios, y el suscriptor solo gestiona su perfil.
  Como criterio, da a cada persona el rol más bajo con el que pueda trabajar: si un cliente solo publica contenido, no necesita ser administrador.
• Usuarios que ya no deben tener acceso.
  Cuando alguien deja el proyecto, elimina su usuario.
  Al borrarlo desde el wp-admin, WordPress pregunta si borrar sus entradas y enlaces o atribuirlos a otro usuario.
  Para no perder contenido, suele convenir atribuirlos.
• Una cuenta por persona.
  Compartir un solo administrador impide saber quién hizo qué y obliga a cambiar la contraseña para todos cuando alguien se va.
  Es criterio propio.

Qué hace y qué no hace un plugin de seguridad para WordPress

Según la documentación oficial y la ficha de estos plugins en el directorio, los plugins de seguridad de WordPress suelen ofrecer:

• Cortafuegos.
  Filtran el tráfico malicioso antes de que WordPress lo procese.
  Algunos actúan a nivel del servidor web, modificando el archivo .htaccess, y otros a nivel de WordPress, mientras este carga.
• Escaneo.
  Buscan malware, redirecciones maliciosas y código inyectado en el núcleo, los temas y los plugins.
  La documentación también destaca monitorizar los cambios en los archivos para reaccionar antes.
• Protección del inicio de sesión.
  Autenticación en dos pasos, límite de intentos de acceso y CAPTCHA en el formulario.

Lo que no hacen importa más con varios sitios bajo gestión:

• No sustituyen las actualizaciones.
  La documentación pone como lo más importante mantener al día WordPress, los plugins y los temas.
  Un cortafuegos puede reducir la exposición, pero no arregla un componente obsoleto.
• No sustituyen las copias.
  La documentación recuerda que el riesgo nunca llega a cero y que hay que planificar la recuperación para que el sitio pueda volver a funcionar.
• Consumen recursos.
  Según la guía sobre fuerza bruta, un plugin que limita los intentos de acceso se ejecuta dentro de PHP y consume recursos bajo un ataque fuerte, por lo que recomienda limitarlos en el servidor o en el borde cuando sea posible.

La documentación menciona como ejemplos de plugins con cortafuegos iThemes Security, All in One WP Security, Wordfence y Shield.
No recomendamos ninguno: depende de qué cubre ya tu hosting y de qué necesitas.
Como criterio, elige uno que se mantenga, del directorio oficial o de una empresa reconocida, y actualízalo como cualquier otro: un plugin de seguridad abandonado es un problema más.

Cómo revisar el estado de seguridad de cada sitio

WordPress trae una herramienta oficial para esto: la pantalla Salud del sitio, en Herramientas → Salud del sitio.
Tiene dos pestañas:

• Estado agrupa los avisos por gravedad: problemas críticos, mejoras recomendadas y pruebas superadas.
  Entre los críticos aparecen, por ejemplo, plugins pendientes de actualizar, una versión de PHP desactualizada o actualizaciones automáticas que no funcionan.
• Información muestra la configuración técnica: versión de WordPress, plugins y temas instalados, permisos de archivos y tamaño del sitio.

La pantalla no escanea malware ni busca vulnerabilidades: revisa la configuración y las versiones.
Sirve como punto de partida para cada sitio, no como una revisión de seguridad completa.

La guía oficial de endurecimiento de WordPress añade medidas que se revisan una vez por sitio, entre ellas:

• Desactivar la edición de archivos desde el panel, con la constante DISALLOW_FILE_EDIT.
• Revisar los permisos de archivos y los privilegios del usuario de la base de datos.
• Eliminar los plugins y temas que no se usan.
• Cambiar el prefijo de las tablas de la base de datos si todavía tiene el valor por defecto.

Errores frecuentes

• Actualizar sin copia previa.
  Convierte una actualización fallida en una noche de trabajo.
  La guía de copias de seguridad explica cómo evitarlo.
• Dejar instalados plugins que no se usan.
  La documentación recomienda borrarlos, no solo desactivarlos.
• Confiar en un plugin de seguridad y dejar de actualizar.
  El plugin no corrige el resto del software del sitio.
• Reutilizar la misma contraseña en varios sitios.
  La documentación recomienda contraseñas únicas y un gestor de contraseñas.
• Instalar plugins o temas de fuentes no confiables.
  La documentación advierte que salirse del repositorio de WordPress.org o de empresas conocidas puede causar problemas.
• No dar de baja a quien ya no trabaja en el proyecto.
  Un usuario olvidado sigue siendo una puerta abierta.
• No saber el estado de cada sitio.
  Con 5 sitios se lleva de memoria.
  Con 20 o 30, sin un panel que reúna lo pendiente de todos, la respuesta a «¿este sitio está al día?» pasa a ser «no lo sé con certeza».

Cómo lo resuelve TutorWP

TutorWP no es un plugin de seguridad ni reemplaza a uno, y tampoco reemplaza a las copias de seguridad: estas se restauran manualmente desde el wp-admin de cada sitio.
Lo que hace es reunir las actualizaciones pendientes de todos tus sitios (núcleo de WordPress, extensiones y diseños) en una sola lista: eliges los sitios, confirmas una vez y se aplican en bloque, con un registro de qué se actualizó en cada sitio y cuándo.
También muestra alertas de estado por sitio, como «WordPress desactualizado» o «Diseños inactivos», y tiene una sección para ver los usuarios de WordPress de cada sitio.
La conexión usa un código de seguridad por sitio: la contraseña de WordPress no viaja ni se guarda.

Si administras varios sitios de clientes, lo que más tiempo se lleva no es actualizar, sino saber dónde hay algo pendiente.
Para eso construimos TutorWP.
Si quieres saber quiénes estamos detrás, conoce al equipo.