Cómo proteger WordPress desde nginx

Cómo proteger WordPress desde nginx

WordPress no solo se protege desde el panel de administración o con plugins. Si usas nginx como servidor web, puedes aplicar una capa adicional de protección antes de que ciertas peticiones lleguen siquiera a WordPress.

En un VPS, una web corporativa, un blog SEO o una plataforma de formación online, proteger WordPress desde nginx ayuda a reducir exposición de archivos sensibles, bloquear rutas innecesarias, ordenar redirecciones, controlar accesos y disminuir ruido automatizado.

Este artículo explica qué medidas tienen sentido desde nginx, qué riesgos reducen y qué errores conviene evitar para no romper la web por exceso de entusiasmo técnico.

Índice

• Por qué proteger WordPress desde nginx
• Qué puede y qué no puede hacer nginx
• Antes de tocar la configuración
• Proteger archivos sensibles de WordPress
• Controlar el acceso a xmlrpc.php
• Reducir ataques contra wp-login.php
• Controlar WP-Cron desde el cron de Linux
• Evitar ejecución peligrosa en uploads
• Bloquear acceso a directorios internos
• Forzar HTTPS correctamente
• Revisar logs después de aplicar reglas
• Errores frecuentes al proteger WordPress desde nginx
• Conclusión
• Preguntas frecuentes

Por qué proteger WordPress desde nginx

nginx es la primera capa que recibe muchas peticiones antes de que lleguen a WordPress. Eso permite filtrar, bloquear o redirigir determinadas solicitudes sin cargar PHP ni consultar la base de datos.

Esto es especialmente útil porque WordPress recibe mucho tráfico automatizado. Bots, escáneres y ataques genéricos prueban rutas conocidas, archivos sensibles y puntos de acceso habituales.

Proteger desde nginx puede ayudar a:

• Reducir peticiones innecesarias a PHP.
• Bloquear acceso a archivos internos.
• Controlar rutas sensibles.
• Mejorar respuesta frente a bots básicos.
• Evitar exposición de configuraciones.
• Ordenar redirecciones HTTP/HTTPS.

Esta capa no sustituye la seguridad general del servidor. Debe apoyarse en una base ya trabajada: proteger un servidor Linux básico, crear usuarios seguros en Linux y configurar fail2ban correctamente cuando proceda.

Qué puede y qué no puede hacer nginx

nginx puede bloquear, permitir, redirigir y gestionar peticiones HTTP antes de que WordPress intervenga. Eso es muy útil, pero no convierte nginx en una solución completa de seguridad.

nginx puede ayudar a:

• Bloquear archivos concretos.
• Evitar ejecución de PHP en ciertas carpetas.
• Limitar acceso a rutas específicas.
• Forzar HTTPS.
• Proteger ciertos patrones de URL.
• Reducir carga causada por peticiones inútiles.

nginx no puede sustituir:

• Actualizaciones de WordPress.
• Contraseñas robustas.
• Doble factor de autenticación.
• Revisión de plugins vulnerables.
• Backups restaurables.
• Permisos correctos del sistema.

Por eso, antes de confiar en reglas nginx, conviene tener una instalación WordPress limpia y mantenible. Si estás montando el sitio desde cero, revisa cómo instalar WordPress manualmente.

Antes de tocar la configuración

Modificar nginx en producción sin copia ni validación puede dejar la web caída. Antes de aplicar reglas de seguridad, conviene trabajar con método.

Antes de tocar nada:

• Haz backup de la configuración nginx actual.
• Comprueba que tienes acceso SSH estable.
• Ten una copia reciente de la web y base de datos.
• Identifica el server block correcto.
• Evita aplicar muchas reglas de golpe.
• Valida sintaxis antes de recargar nginx.
• Prueba la web después de cada cambio importante.

La comprobación básica es:

sudo nginx -t

Si la configuración es válida, normalmente se puede recargar nginx:

sudo systemctl reload nginx

Si necesitas repasar el funcionamiento de nginx antes de aplicar reglas, el artículo base es cómo instalar nginx correctamente.

Proteger archivos sensibles de WordPress

WordPress incluye archivos que no deberían exponerse públicamente o que conviene limitar. Algunos no son peligrosos por sí solos, pero pueden dar información útil a atacantes o revelar detalles innecesarios.

Archivos a revisar:

• wp-config.php
• readme.html
• license.txt
• Archivos de copia con extensiones como .bak, .old o .save.
• Archivos ocultos como .git o configuraciones temporales.

Un bloque conceptual para negar acceso a ciertos archivos podría ser:

location ~* /(wp-config.php|readme.html|license.txt) {
    deny all;
}

Este tipo de regla debe adaptarse a la configuración real. No conviene copiar y pegar sin probar, porque cada server block puede tener particularidades.

Además, bloquear archivos desde nginx no sustituye tener permisos adecuados en Linux. Ambas capas deben trabajar juntas.

Controlar el acceso a xmlrpc.php

xmlrpc.php es una ruta conocida de WordPress que históricamente se ha usado para integraciones, publicación remota y ciertas funciones. También es una ruta muy probada por bots.

En muchas webs modernas no se necesita. Si no se usa, puede bloquearse desde nginx para reducir ruido y ataques automatizados.

Ejemplo conceptual:

location = /xmlrpc.php {
    deny all;
}

Antes de bloquearlo, conviene comprobar si algún plugin, aplicación móvil, integración externa o sistema de publicación lo necesita. Bloquearlo sin revisar puede romper funcionalidades legítimas.

Si recibes muchas peticiones a xmlrpc.php, probablemente también conviene revisar cómo evitar ataques automáticos a tu servidor.

Reducir ataques contra wp-login.php

wp-login.php es uno de los objetivos más habituales de intentos automáticos. nginx puede ayudar a limitar exposición, aunque hay que hacerlo con cuidado para no bloquear usuarios legítimos.

Opciones posibles:

• Limitar acceso por IP si administras siempre desde ubicaciones conocidas.
• Aplicar protección adicional mediante autenticación básica.
• Combinar logs de nginx con fail2ban.
• Reducir intentos repetidos desde mismas IPs.

Un bloqueo por IP puede ser muy efectivo, pero poco práctico si administras desde redes cambiantes. La protección básica HTTP puede añadir una barrera, pero también puede incomodar a usuarios o integraciones.

La protección del login no debería depender solo de nginx. También conviene usar contraseñas robustas, usuarios no evidentes y doble factor cuando proceda.

Controlar WP-Cron desde el cron de Linux

Por defecto, WordPress ejecuta tareas programadas mediante un sistema llamado WP-Cron. A diferencia del cron tradicional de Linux, este mecanismo se activa cuando alguien visita la web. Eso significa que publicaciones programadas, limpiezas, sincronizaciones o ciertos plugins pueden ejecutarse de forma irregular o depender del tráfico recibido.

En servidores VPS, instalaciones WordPress administradas directamente o proyectos con cierto nivel técnico, suele ser recomendable desactivar el disparo automático interno y delegar la ejecución al cron real de Linux. Esto aporta un comportamiento más predecible y evita ejecuciones innecesarias disparadas por bots o visitas repetitivas.

La desactivación del disparo automático interno suele hacerse en el archivo wp-config.php:

define('DISABLE_WP_CRON', true);

Después, puede programarse una llamada periódica desde cron Linux. Una opción habitual consiste en llamar al cron de WordPress mediante HTTP local:

*/5 * * * * curl -s https://tudominio.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Otra alternativa consiste en ejecutar directamente PHP desde el sistema, adaptando la ruta real de la instalación:

*/5 * * * * php /ruta/a/tu/wordpress/wp-cron.php >/dev/null 2>&1

El intervalo depende del proyecto. Para muchas webs corporativas, blogs profesionales o plataformas LMS pequeñas, ejecutar el cron cada pocos minutos suele ser suficiente. No siempre tiene sentido ejecutar tareas cada minuto.

Antes de aplicar este cambio, conviene comprobar si WordPress realmente depende de tareas programadas importantes: publicaciones automáticas, envío de emails, sincronizaciones, limpieza de cachés o plugins concretos.

Esta medida no es estrictamente una regla nginx, pero sí forma parte de una estrategia razonable de endurecimiento, control operativo y optimización de WordPress administrado sobre VPS.

Si observas procesos PHP recurrentes o consumo extraño de CPU, conviene revisar también cómo detectar consumo excesivo de CPU y cómo monitorizar recursos del servidor.

Evitar ejecución peligrosa en uploads

La carpeta wp-content/uploads está pensada para almacenar imágenes, documentos y medios subidos. No debería usarse para ejecutar código PHP.

Una medida habitual es impedir ejecución PHP dentro de uploads. Esto reduce impacto si alguien logra subir un archivo malicioso disfrazado.

Ejemplo conceptual:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

Esta regla ayuda a bloquear ejecución de archivos PHP en uploads, pero debe probarse en la instalación real.

Además, conviene revisar permisos de carpetas y limitar tipos de archivo permitidos desde WordPress o plugins. nginx es una capa; WordPress y Linux siguen teniendo responsabilidad.

Bloquear acceso a directorios internos

Algunos directorios de WordPress no deberían exponerse libremente como listado de archivos ni permitir acceso directo a elementos internos innecesarios.

Hay que prestar atención a:

• wp-includes
• Archivos internos de plugins.
• Directorios de caché.
• Copias temporales.
• Carpetas de desarrollo o despliegue.

No conviene bloquear directorios enteros sin entender cómo WordPress los usa. Algunas rutas internas sirven recursos necesarios para el funcionamiento del sitio.

La estrategia correcta no es cerrar todo a martillazos, sino bloquear lo que claramente no debe ser público y probar que la web sigue funcionando.

Forzar HTTPS correctamente

nginx suele encargarse de redirigir tráfico HTTP hacia HTTPS. Esto es importante para seguridad, coherencia de URLs y confianza del usuario.

Una web WordPress profesional debería tener:

• Certificado válido.
• Redirección HTTP a HTTPS.
• Coherencia entre www y sin www.
• Sin contenido mixto.
• URL del sitio configurada correctamente en WordPress.

Una redirección mal planteada puede generar bucles o duplicidades. Por eso HTTPS debe configurarse con cuidado desde el servidor y desde WordPress.

Si todavía no has configurado el certificado, sigue cómo configurar HTTPS gratis con Let’s Encrypt.

Revisar logs después de aplicar reglas

Después de aplicar reglas nginx, hay que mirar logs. No basta con que la portada cargue.

Conviene revisar:

• Errores 403 inesperados.
• Errores 404 en recursos legítimos.
• Errores 500.
• Recursos CSS o JavaScript bloqueados.
• Peticiones repetidas a rutas sensibles.
• Accesos legítimos bloqueados por accidente.

Logs útiles:

tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log

Si tras proteger la web aumenta el consumo o aparecen errores, revisa cómo monitorizar recursos del servidor y cómo detectar consumo excesivo de CPU.

Errores frecuentes al proteger WordPress desde nginx

El error más común es aplicar reglas encontradas en Internet sin entenderlas. Muchas configuraciones dependen de la versión de nginx, estructura de WordPress, PHP-FPM, plugins y rutas reales.

Errores habituales:

• No hacer backup de la configuración nginx.
• No validar con nginx -t.
• Bloquear xmlrpc.php sin comprobar integraciones.
• Limitar wp-login.php y bloquear administradores legítimos.
• Romper recursos CSS o JavaScript.
• Aplicar demasiadas reglas de golpe.
• No revisar logs después.
• Confundir reglas nginx con seguridad completa.
• No mantener WordPress actualizado.

La seguridad efectiva suele ser sobria. Mejor pocas reglas entendidas y probadas que una configuración enorme imposible de mantener.

Conclusión

Proteger WordPress desde nginx permite añadir una capa muy útil antes de que las peticiones lleguen al CMS. Puede bloquear archivos sensibles, reducir ataques automatizados, controlar rutas como xmlrpc.php y reforzar HTTPS.

Pero nginx no sustituye el mantenimiento de WordPress ni la seguridad del servidor. Debe combinarse con actualizaciones, usuarios seguros, permisos correctos, backups, monitorización y revisión de logs.

La mejor protección desde nginx es la que reduce riesgos sin romper la operativa normal de la web.

Para una microempresa, un blog SEO o una plataforma online, esta capa aporta control y eficiencia, siempre que se aplique con método y no como una colección de reglas copiadas sin criterio.

Preguntas frecuentes