¿Qué ocurre si un plugin vulnerable compromete la red y deja inaccesibles decenas de sitios durante horas? La red Multisite comparte código, datos y privilegios, por lo que la superficie de ataque y el impacto operativo son muy superiores a una instalación única; fallos en plugins, certificados o backups mal gestionados pueden multiplicar costes, SLAs y pérdida de confianza.
Para la Seguridad WordPress, se deben aplicar actualizaciones automáticas controladas, políticas estrictas de superadmin y permisos de archivos, activar SSL wildcard o SAN por dominio, realizar backups integrales y pruebas de restauración por sitio, usar WP-CLI para automatizar comprobaciones y configurar monitoreo y un plan de respuesta a incidentes, lo que reduce downtime y facilita la recuperación por sitio. Se recomienda comenzar por un hardening del wp-config.php y automatizar verificaciones.
Seguridad WordPress multisite: fundamento técnico y riesgo
La red Multisite comparte código y privilegios entre sitios y por eso el riesgo es mayor que en una instalación única. Si un plugin con permisos de activación de red falla, puede afectar a todos los sitios. El error más frecuente en este punto es tratar la red como si fueran sitios independientes y activar plugins globalmente sin evaluar impacto.
Proteger las constantes críticas de wp-config.php reduce la posibilidad de escalado. Entre las constantes a fijar están MULTISITE, DOMAIN_CURRENT_SITE, COOKIE_DOMAIN y las AUTH_KEYS que aseguran cookies y sesiones. Muchas auditorías muestran que fallos en wp-config y permisos de archivo son vectores de escalado de privilegios.
Un control efectivo combina: políticas de superadmin estrictas, permisos de archivos y directorios, cortafuegos a nivel de aplicación y servidor, SSL gestionado y backups que permitan restaurar sólo el sitio afectado. El objetivo es reducir el blast radius: cuanto más se aíslen recursos, menor el daño por compromiso.
Constantes clave para multisite
Fije MULTISITE a true y DOMAIN_CURRENT_SITE a su dominio principal en wp-config.php. Defina COOKIE_DOMAIN para evitar cookies globales inesperadas. Pase WP_DEBUG a false en producción para no revelar rutas ni variables.
Asegure las AUTH_KEYS y SALTS y rote estos valores ante sospecha de filtro de credenciales. Bloquear wp-config.php con permisos 440 y propietario root:www-data limita su lectura desde el usuario web.
Permisos y ownership recomendados
Use chmod 440 para wp-config.php y 750 para directorios en la instalación. Asigne owner root y group al usuario de la web (por ejemplo www-data). Revise permisos de uploads y plugins; los archivos PHP nunca deben ser escribibles por el usuario web.
Proteger wp-config.php con permisos 440 y ownership root:www-data reduce drásticamente la posibilidad de escalado de privilegios en Multisite.
Hardening práctico de wp-config.php
Además de fijar constantes, conviene aplicar pasos reproducibles que endurezcan wp-config.php y permitan mantener actualizaciones controladas mediante despliegue automatizado. Por ejemplo, desde la shell (como root) se puede fijar propiedad y permisos seguros: chown root:www-data /var/www/html/wp-config.php && chmod 440 /var/www/html/wp-config.php y, opcionalmente, aplicar inmutabilidad en sistemas con ext4: chattr +i /var/www/html/wp-config.php (recuerde quitar +i antes de actualizar el fichero). Para establecer constantes desde la línea de comando use WP-CLI: wp config set DISALLOW_FILE_EDIT true --raw --path=/var/www/html y wp config set DISALLOW_FILE_MODS true --raw --path=/var/www/html para evitar ediciones desde el dashboard; active SSL en admin con wp config set FORCE_SSL_ADMIN true --raw. Las claves SALT hay que rotarlas sólo tras incidentes o restauraciones: genere nuevas claves con curl -s https://api.wordpress.org/secret-key/1.1/salt/ y reemplace el bloque en wp-config (o use un script CI que inyecte las claves en despliegues), siempre teniendo en cuenta que rotar salts invalidará sesiones activas.
Este enfoque permite hardening real y, al mismo tiempo, soportar actualizaciones mediante procesos de despliegue (CI/CD, actualizaciones vía WP-CLI en ventanas de mantenimiento o provisionamiento controlado) sin impedir las actualizaciones.
Reglas servidor y bloqueos: nginx, apache y .htaccess
Aplicar reglas en el servidor filtra ataques antes de que lleguen a PHP. Rate limiting, bloqueo de xmlrpc.php y reglas para /wp-admin reducen fuerza bruta y abuso de API. Un WAF en frontales críticos añade una capa de defensa útil.
Los snippets de servidor permiten respuestas rápidas y reproducibles en despliegues. Aquí hay ejemplos concretos que sirven en la mayor parte de hosts gestionados o VPS.
Ejemplo nginx: limitación y bloqueo
Use estas directivas para limitar peticiones y bloquear xmlrpc:
- nginx limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s
- server { listen 443 ssl
- server_name ejemplo.com
- location /xmlrpc.php { return 403; }
- location /wp-login.php { limit_req zone=one burst=20 nodelay; }
- add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always
- }
La directiva rate=10r/s fija un límite práctico para tráfico legítimo de usuario humano. Esto reduce intentos de fuerza bruta sin afectar la mayoría de visitantes.
Apache y .htaccess: reglas y cabeceras
Para Apache use mod_security, mod_evasive y .htaccess con cabeceras de seguridad. Ejemplo mínimo:
apache
RewriteEngine On
RewriteRule ^xmlrpc.php - [F]
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "no-referrer-when-downgrade"
Ajuste IP allow/deny para /wp-admin si la operación lo admite. Esto evita accesos administrativos desde localizaciones no autorizadas.
Ejemplo completo de configuración nginx
Un servidor nginx correcto para Multisite necesita server_name wildcard, reglas try_files y bloqueo de PHP en uploads; un bloque de ejemplo (HTTPS) sería:
nginx
server {
listen 443 ssl http2;
server_name .ejemplo.com; # wildcard para subdominios
root /var/www/html;
index index.php;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ /(?:uploads|files)/..php$ {
deny all;
return 404;
}
location ~ .php$ {
include fastcgi_params;
fastcgi_split_path_info ^(.+.php)(/.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php-fpm.sock; # ajustar según su PHP-FPM
}
location = /xmlrpc.php { deny all; }
}
Para subdirectory Multisite use la misma try_files pero asegúrese de que SUBDIRECTORY_INSTALL esté configurado correctamente y de que el servidor atienda el dominio principal sin wildcard. No olvide el wildcard DNS A/CNAME y configurar ACME DNS-01 para certificados wildcard.
SSL/TLS escalable: wildcard y certificados SAN
Las redes con muchos subdominios suelen usar certificados wildcard (*.dominio) para cubrir todos los subdominios. Para múltiples dominios use certificados SAN que listan dominios distintos en un solo certificado. Automatizar la renovación evita caídas por expiración.
Para emitir wildcard con Let's Encrypt use ACME DNS-01 y automatice la renovación con scripts que interactúen con el proveedor DNS. Renueve certificados antes de 60 días para margen operativo.
Wildcard vs SAN: ventajas y uso
Let's Encrypt wildcard: gratis, requiere DNS-01, cubre subdominios y sirve bien si todos los sitios comparten un dominio. Certificado SAN comercial: maneja dominios heterogéneos y suele incluir soporte y garantía.
Un certificado wildcard requiere control del DNS. Si hay muchos dominios con dueños distintos, SAN o certificados individuales gestionados por un CDN son más prácticos.
Automatizar emisión con certbot
Comando ejemplo para DNS-01 con certbot y proveedor que soporte API:
bash
certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/cloudflare.ini -d "*.ejemplo.com" -d ejemplo.com --non-interactive --agree-tos
Programar cron para renovar y recargar nginx/apache 30 días antes de expiración. Esto evita problemas por renovación manual olvidada.
Backups y restauración por sitio: el playbook operativo
Un backup que no se prueba no sirve en incidentes reales. Las redes Multisite deben tener backups diarios de ficheros y base de datos y pruebas trimestrales de restauración por sitio. Separar tablas globales de tablas por sitio facilita restauraciones parciales.
La lista mínima de tablas de un sitio 2 incluye wp_2_posts, wp_2_options, wp_2_postmeta, wp_2_terms, wp_2_term_taxonomy, wp_2_term_relationships y wp_2_comments. Restaurar solo estas tablas recupera el sitio sin afectar el resto.
Los snapshots incrementales de almacenamiento y backups fuera del servidor reducen el riesgo de pérdida por fallo del host.
Esquema de backups y tablas
Haga backups completos diarios y snapshots incrementales cada 6 horas para archivos. Mantenga al menos 30 días de copias diarias y 90 días de metadatos para análisis forense. Realice una copia semanal fuera de la misma región.
Un caso habitual: se realiza un backup diario pero no se separan las tablas por sitio; tras un ataque se restaura toda la base de datos y se pierde historial o configuraciones de otros sitios.
Playbook de restauración por sitio
- Identificar ID del sitio afectado y detener su tráfico (mantener el resto en línea).
- Bloquear acceso público al sitio afectado y a la zona de administración.
- Exportar tablas wp_X_* del backup verificado y restaurarlas en la base de datos.
- Restaurar uploads específicos en wp-content/uploads/sites/X.
- Forzar rotación de claves SALT y rotar credenciales administrativas del sitio.
- Escanear archivos restaurados antes de reabrir.
- Reabrir el sitio y monitorizar logs 72 horas.
Pruebe este playbook en entorno staging al menos cada tres meses.
Automatización práctica de backup y restauración
Para restaurar un único sitio en una red Multisite es útil scriptar mysqldump de las tablas wp_X_* y sincronizar uploads: por ejemplo, exportar tablas del sitio ID 2 con mysqldump:
bash
mysqldump -u backupuser -p'SECRETPASS' --single-transaction --skip-lock-tables dbname /
wp_2_posts wp_2_postmeta wp_2_options wp_2_terms wp_2_term_taxonomy wp_2_term_relationships wp_2_comments > site2.sql
Restaurar con: mysql -u root -p dbname < site2.sql. Para archivos: rsync -av --delete /backups/uploads/sites/2/ /var/www/html/wp-content/uploads/sites/2/. Después de importar, ejecute WP-CLI para normalizar URLs y objetos serializados: wp search-replace 'backup.ejemplo.com' 'ejemplo.com' --skip-columns=guid --precise --recurse-objects --path=/var/www/html --url=ejemplo.com. Para automatizar: cree un script que haga mysqldump+rsync+verificación MD5 y prográmelo con cron (0 2 * * * /usr/local/bin/backup_multisite.sh) y añada comprobaciones que validen la restauración en staging antes de aplicar en producción. Estos comandos permiten restauraciones por sitio reproducibles y auditables en Multisite.
Matriz de riesgo de plugins y automatización con WP-CLI
Evaluar plugins por frecuencia de actualizaciones, historial de vulnerabilidades, alcance de activación y dependencia en mu-plugins ayuda a decidir si activar en red. Automatizar la auditoría con WP-CLI genera reportes reproducibles.
La matriz clasifica impacto en alto, medio o bajo según si el plugin ejecuta código remoto, escribe en opciones globales o requiere privilegios de superadmin.
| Criterio |
Descripción |
Medida |
| Frecuencia de updates |
Días desde la última release |
Valor: 0-90 días = bueno |
| Historial CVE |
Número de vulnerabilidades públicas en 3 años |
Valor: 0 = bajo, 1-2 = medio, 3+ = alto |
| Alcance de activación |
Activación por red o por sitio |
Recomendado: activar por sitio si es posible |
Comandos WP-CLI para auditoría
Listado y estado de plugins:
bash
wp plugin list --format=csv > plugins.csv
wp plugin update --dry-run --all
Buscar plugins activos en la red:
bash
wp site list --field=blog_id | xargs -n1 -I % wp plugin list --url=% --status=active
Automatizar con cron para generar reportes diarios y alertas sobre plugins sin actualizar.
Monitorización, logging y playbook de incidentes
Vigilar integridad de archivos, accesos y logs de aplicación reduce el tiempo medio de detección. Conservar logs de 90 días facilita el análisis forense y la respuesta coordinada. Integrar con un SIEM externo permite correlar eventos y detectar patrones.
El playbook de incidentes reduce errores operativos. Mantener pasos claros y un responsable reduce el tiempo de recuperación y evita restauraciones innecesarias.
Checklist 8 pasos de respuesta
- Aislar el sitio comprometido para evitar propagación.
- Requerir autenticación fuerte y bloquear sesiones activas.
- Revocar tokens de API y claves de aplicación.
- Restaurar desde un backup verificado por sitio.
- Analizar logs y traza de incidentes para vector de entrada.
- Rotar credenciales y salts.
- Parchear el vector y actualizar componentes.
- Comunicar el incidente y documentar la lección aprendida.
Los expertos recomiendan mantener pruebas de este checklist al menos cada seis meses.
Integración con SIEM y alertas
Enviar logs de acceso y aplicación a un SIEM permite reglas de correlación y creación de alertas. Soluciones como Sucuri, Wordfence o servicios gestionados de Kinsta y Pantheon ofrecen capas adicionales de detección. Para estándares de seguridad en España consulte a INCIBE.
Enlaces de referencia: OWASP Top 10 y INCIBE.
Retener logs de acceso y aplicación al menos 90 días facilita la investigación y la trazabilidad tras un incidente.
Hardening
wp-config, permisos
›
WAF + Server Rules
nginx / Apache
›
Backups + Playbook
Restore por sitio
Segmentación, políticas y migración segura
Separar recursos físicos y lógicos reduce el radio de contagio ante una brecha. Para más de 25 sitios o clientes distintos, segmentar almacenamiento y usar buckets o contenedores por cliente limita el impacto. Esto mejora gobernanza y facilita cumplimiento normativo.
Al migrar hacia Multisite debe preservarse el ID de posts y los salts en wp-config para evitar problemas de permiso y cookies inválidas. No mantener dichos valores rompe sesiones y puede causar errores de acceso.
Un error concreto es migrar sin mapear dominios y sin conservar las tablas wp_X_*. Esto provoca pérdida de contenido y enlaces rotos.
Cuándo evitar multisite
Evitar Multisite si cada cliente necesita aislamiento total por cumplimiento o si los plugins críticos son incompatibles entre sí. Para una sola web pequeña sin planes de expansión no compensa la complejidad adicional.
Migración segura y preservación de IDs
Exportar e importar tablas wp_X_* directamente y mantener las mismas claves SALT preserva autenticaciones. Use WP-CLI y mysqldump con condiciones WHERE para tablas específicas y valide integridad tras la importación.
Bash
mysqldump -u root -p --single-transaction --skip-lock-tables dbname wp_2_posts wp_2_postmeta wp_2_options > site2.sql
wp db import site2.sql --path=/var/www/html
Contacte con un servicio de mantenimiento si necesita delegar pruebas de restauración o la automatización de certificados y WP-CLI en infraestructuras críticas.
Preguntas frecuentes sobre multisite y seguridad
¿Qué es WordPress multisite?
WordPress Multisite es una red que permite gestionar múltiples sitios desde una única instalación. Esta arquitectura comparte código y base de datos, lo que reduce costes pero aumenta el riesgo si falla un componente.
¿Es seguro usar WordPress multisite?
Sí, siempre que se apliquen controles adicionales respecto a una instalación única. Las medidas clave son hardening de wp-config, backups por sitio y políticas estrictas de superadmin; sin ellas el riesgo crece considerablemente.
¿Cómo mejorar la seguridad en una red WordPress?
Aplique permisos estrictos, WAF, SSL automatizado y auditorías periódicas con WP-CLI. Hacer pruebas de restauración trimestrales verifica que los backups son útiles en la práctica.
¿Cómo hacer copias de seguridad de una red Multisite?
Haga backups diarios de ficheros y base de datos y mantenga snapshots incrementales cada 6 horas. Separe tablas por sitio y pruebe la restauración por sitio cada tres meses para garantizar recuperación rápida.
¿Cuándo conviene usar WordPress multisite y cuándo no?
Conviene si se gestionan muchos sitios con requisitos homogéneos y se busca eficiencia operacional. No conviene si cada cliente exige aislamiento o si los plugins son incompatibles entre sitios.
¿Puedo instalar plugins en un solo sitio de la red?
Sí, se pueden instalar plugins por sitio o activarlos en red. Activar en red aumenta el riesgo; siempre evalúe impacto antes de activar globalmente.
¿Se puede usar SSL en multisite con dominios distintos?
Sí, use certificados SAN para varios dominios o un certificado por dominio gestionado por un CDN. Para wildcard automatice con DNS-01 cuando los sitios comparten dominio.
El plan concreto
Priorice estas acciones en el orden dado: asegurar wp-config.php y permisos, automatizar SSL, configurar reglas de servidor y WAF, crear backups diarios y pruebas trimestrales, automatizar auditorías con WP-CLI y definir un playbook de incidentes. Haga pruebas de todo en un entorno staging antes de aplicar en producción.
Esto no funciona si la operación pide aislamiento total por cumplimiento o si los plugins críticos no funcionan en Multisite. En esos casos, debe optarse por instalaciones separadas y recursos dedicados.
Preguntas adicionales sobre migraciones o pruebas de restauración se responden mediante diagnóstico previo y validación del entorno.
