Auditar la seguridad de un Linux que sirve WordPress es, o debería ser, lo primero que hace un administrador antes de blindar nada. Lo digo por experiencia: la mayoría de las infecciones que llegan a servidores de hosting compartido o VPS no vienen de vulnerabilidades exóticas. Vienen de descuidos. Contraseñas flojas, permisos mal puestos, plugins que llevan meses sin actualizarse, cuentas SSH con más privilegios de los necesarios. Nada glamuroso. En esta guía repasamos, paso a paso, lo esencial que hay que revisar en el servidor para que tu WordPress se apoye en una base sólida.
Preparación previa: acceso, copias de seguridad e inventario del servidor
Antes de tocar nada, dos cosas: acceso root o sudo al servidor y una copia de seguridad completa. Y verificada, no basta con que exista. Una auditoría implica cambiar configuraciones y permisos, y un despiste puede dejar el sitio caído. Haz como mínimo esto:
- Copia de la base de datos: con mysqldump -u usuario -p nombre_bd > backup.sql o desde phpMyAdmin.
- Copia de los archivos: tar -czvf backup_web.tar.gz /var/www/tudominio.com.
- Instantánea del servidor: si trabajas con un VPS, crea un snapshot desde el panel de tu proveedor.
Luego, inventario. Qué versión de sistema operativo corres (cat /etc/os-release), qué versión de PHP y de MySQL/MariaDB, qué servicios están escuchando en red (ss -tulpn) y qué versión de WordPress y plugins tienes instalados. Con eso sobre la mesa resulta mucho más fácil cazar software obsoleto y servicios que sobran, dos de los vectores de ataque más habituales (y de los más silenciosos).
Consejo práctico: documenta todo lo que encuentres en un archivo de texto, con fecha. Sin ese registro previo no tendrás contra qué comparar dentro de seis meses, y muchos problemas de seguridad se detectan justo ahí, al contrastar el estado actual con el original.
Revisión de usuarios, contraseñas y acceso SSH
El acceso al sistema es la primera muralla. Empieza listando quién tiene shell activa: mira /etc/passwd y comprueba que solo los usuarios necesarios tienen /bin/bash o similar. Los usuarios de sistema deberían tener /usr/sbin/nologin. ¿Sobran cuentas? Desactívalas sin piedad.
Después revisa quién pertenece al grupo sudo con getent group sudo y quita los privilegios que no se justifiquen. Cada cuenta con sudo es una puerta más para un atacante. No lo olvides.
Y en SSH, estas comprobaciones sobre /etc/ssh/sshd_config:
- Pon PermitRootLogin no para cerrar la puerta al forceo bruto sobre root.
- Desactiva la autenticación por contraseña con PasswordAuthentication no y usa claves SSH.
- Cambia el puerto por defecto 22 si el entorno lo permite. No es seguridad real, pero reduce el ruido de bots de forma notable.
- Reinicia el servicio con systemctl restart sshd y, muy importante, verifica que conectas con la nueva configuración antes de cerrar la sesión actual. Me ha tocado ver a más de uno quedarse fuera de su propio servidor por saltarse este paso.
Como complemento, instala fail2ban: bloquea automáticamente las IP que acumulan intentos fallidos de login. Y echa un ojo a /var/log/auth.log (o /var/log/secure en CentOS/RHEL) para ver qué patrones de ataque ha habido recientemente. Suele sorprender.
Auditoría de seguridad Linux WordPress: permisos de archivos y carpetas
Los permisos incorrectos son una de las causas más frecuentes de compromiso en WordPress. La regla que recomienda el propio proyecto WordPress es sencilla:
- Carpetas: 755 (el propietario escribe, el resto solo lee y ejecuta).
- Archivos: 644 (el propietario escribe, el resto solo lee).
- wp-config.php: 600 o 640, porque ahí viven las credenciales de la base de datos.
Para corregir permisos de forma masiva desde la raíz de tu instalación:
find /var/www/tudominio.com -type d -exec chmod 755 {} \;
find /var/www/tudominio.com -type f -exec chmod 644 {} \;
chmod 600 /var/www/tudominio.com/wp-config.php
Tan importante como los permisos es el propietario de los archivos. Si el servidor web corre como www-data (Debian/Ubuntu) o nginx/apache (CentOS), lo más sensato es que los archivos pertenezcan a tu usuario y el grupo al usuario del servidor web, sin darle propiedad total: chown -R usuario:www-data /var/www/tudominio.com. Aquí no hay margen: jamás asignes la propiedad a www-data. Si alguien explota un plugin, tendría permiso para escribir código en todo el sitio.
Última pasada: comprueba que no queden archivos con permisos 777 ni PHP sospechosos en wp-content/uploads. Ese directorio no debería ejecutar código. Nunca.
Análisis de WordPress: plugins, temas, usuarios y malware
WordPress core, por lo general, aguanta bastante bien el tipo. Donde de verdad se cuece la mayoría de las intrusiones es en plugins y temas, sobre todo en los que llevan años abandonados o que alguien descargó de una web cualquiera en vez del repositorio oficial. Lo primero: hazte una lista de lo que tienes instalado y en qué versión.
Con WP-CLI es rápido. Lanza wp plugin list –status=active –field=name y wp theme list, y luego contrasta cada versión con su changelog oficial. Un plugin sin actualizaciones desde hace más de un año, y sin alternativa mantenida, es un candidato clarísimo a la eliminación. Y ojo con las categorías problemáticas de siempre: constructores de formularios, plugins que permiten subir archivos y sliders antiguos. Ahí se concentra buena parte de las vulnerabilidades que veo reportadas.
Revisa también los usuarios registrados en la base de datos. Suena obvio, pero es más común de lo que parece encontrar cuentas de administrador creadas por un atacante con nombres discretos, casi invisibles entre el resto. Compruébalo con wp user list –role=administrator y elimina cualquier cuenta que no reconozcas. De paso, verifica que el administrador legítimo no se llame «admin» y activa la autenticación en dos pasos, como mínimo, para los roles con privilegios.
Para la caza del malware, conviene combinar varias herramientas (ninguna sola da garantías):
- wp core verify-checksums y wp plugin verify-checksums para detectar archivos del núcleo o de plugins que han sido modificados.
- grep -rl «eval(base64_decode» /var/www/html para localizar la ofuscación típica de los webshells.
- ClamAV con clamscan -r /var/www/html como barrido general complementario.
- Herramientas específicas como Wordfence CLI o maldet, que trabajan con firmas de malware pensadas para WordPress.
Un detalle que muchos se saltan: los atacantes suelen reinyectar el malware mediante tareas cron de WordPress o mediante entradas huérfanas en la base de datos. Merece la pena revisar la tabla wp_options (el campo cron) y buscar iframes o scripts insertados en wp_posts con una consulta sobre el contenido que contenga «script» o «iframe» en posteos publicados.
Firewall, puertos abiertos y servicios en escucha
La auditoría a nivel de red completa lo hecho a nivel de aplicación. Y aquí el primer paso es sencillo: saber exactamente qué está expuesto. Ejecuta ss -tulpn en el servidor y anota cada servicio en escucha. Lo razonable es encontrar únicamente los puertos 80 y 443 (y el 22, si gestionas por SSH). Todo lo demás (MySQL, Redis, Memcached, paneles) debería escuchar en 127.0.0.1 o estar filtrado. Sin excusas.
Un error muy frecuente en servidores LEMP es dejar MySQL escuchando en 0.0.0.0 con una contraseña débil. Una combinación peligrosa. Revisa en /etc/mysql/mariadb.conf.d/50-server.cnf (o el equivalente en tu distribución) que exista la directiva bind-address = 127.0.0.1.
Después tocan las reglas del firewall. Si trabajas con UFW:
- ufw status verbose para ver el estado actual.
- Permite solo 22, 80 y 443 desde donde corresponda; si gestionas desde una IP fija, restringe SSH a esa IP.
- Instala fail2ban con jails para sshd y para los logs de WordPress (wp-login.php y xmlrpc.php), bloqueando los intentos repetidos de autenticación.
¿Usas Cloudflare u otro CDN? Entonces puedes apretar aún más: permitir el tráfico 80/443 únicamente desde los rangos IP del proveedor y desactivar XML-RPC por completo si no lo necesitas. Es un vector clásico de fuerza bruta y de abuso mediante pingback.
Conclusión: checklist final y próximos pasos de hardening
Una auditoría de seguridad Linux WordPress no es algo que se hace una vez y ya está. Es un proceso repetible, casi rutinario. Para no perder el hilo, resume tu trabajo en esta lista de verificación:
- Sistema actualizado: kernel, paquetes y PHP en versión soportada.
- Permisos correctos: 644/755, propiedad adecuada y sin 777.
- Plugins y temas al día, sin software abandonado ni nulled.
- Usuarios revisados, sin cuentas fantasma y con 2FA activo.
- Checksums del núcleo verificados y malware descartado o eliminado.
- Firewall restrictivo, fail2ban operativo y solo los puertos necesarios en escucha.
- Copias de seguridad automáticas, externas y probadas mediante restauración real. (Una copia sin probar no es una copia.)
Como siguientes pasos de hardening, plantea migrar a PHP 8.x con las cabeceras de seguridad activas (CSP, HSTS, X-Frame-Options), separar la base de datos en un host interno, implantar autenticación SSH exclusivamente por clave y monitorizar cambios de archivos con AIDE o una herramienta similar. Y si tras esta auditoría detectas compromiso activo, o simplemente prefieres que un profesional revise tu servidor, en RedServicio (redservicio.net) encontrarás soporte experto en administración Linux, limpieza de malware WordPress y hardening completo de servidores.
