Proteger wp-login.php con autenticación básica en Nginx y Apache

De todas las medidas de seguridad que puedes aplicar a un WordPress, proteger wp-login.php es probablemente la que mejor relación ofrece entre esfuerzo y resultado. Ese archivo es la puerta de entrada al panel de administración y, por eso mismo, el objetivo favorito de los bots que lanzan ataques de fuerza bruta contra millones de sitios cada día. Si pones una capa de autenticación básica HTTP (Auth Basic) delante del formulario de login, bloqueas la inmensa mayoría de esos intentos antes de que lleguen a PHP. Menos carga en el servidor. Menos riesgo de compromiso.

Por qué proteger wp-login.php es crítico para tu WordPress

Piensa en lo que ocurre con cada intento de acceso a wp-login.php: WordPress carga completo. Plugins, temas, consultas a la base de datos. Todo. Y los bots automatizados no hacen una petición y ya; pueden lanzar cientos o miles por minuto, lo que se traduce en picos de CPU, un sitio que va a trompicones y, en servidores ajustados de recursos, caídas del servicio. Si encima el ataque de fuerza bruta tiene éxito, el problema ya es otro: acceso total a la instalación, malware, redirecciones a sitios de spam, SEO tóxico, robo de datos.

La autenticación básica funciona como un primer candado a nivel de servidor web. Antes de que Nginx o Apache procesen una sola línea de PHP, el visitante tiene que demostrar quién es. Los bots sin credenciales reciben un 401 y no llegan ni a rozar WordPress. ¿Qué ganas exactamente con esto?

• Menos carga del servidor: las peticiones se rechazan en milisegundos, sin ejecutar PHP ni tocar la base de datos.
• Bloqueo masivo de ataques: la mayoría de bots no están preparados para superar dos autenticaciones encadenadas.
• Defensa en profundidad: aunque un atacante descubra tu contraseña de WordPress, todavía necesitaría las credenciales del servidor.
• Sin plugins: no añades peso a WordPress ni abres nuevas superficies de ataque.

En RedServicio (redservicio.net) aplicamos esta configuración de forma habitual en nuestros servidores gestionados. La combinación de Auth Basic con límites de tasa en Nginx elimina prácticamente todo el ruido de los ataques automatizados. Es un cambio pequeño que se nota desde el primer día.

Cómo generar el archivo de contraseñas htpasswd

Lo primero es crear el archivo con el usuario y la contraseña cifrados. En Linux tienes la utilidad htpasswd, incluida en el paquete apache2-utils (Debian/Ubuntu) o httpd-tools (CentOS/AlmaLinux):

Instalado el paquete, generas el archivo así:

1. Ejecuta sudo htpasswd -c /etc/nginx/.htpasswd usuario. El flag -c crea el archivo; úsalo solo la primera vez, porque sobrescribe lo que hubiera.
2. Introduce la contraseña dos veces cuando el sistema la pida.
3. ¿Usuarios adicionales más adelante? Omite el flag: sudo htpasswd /etc/nginx/.htpasswd usuario2.

El archivo resultante tendrá una línea parecida a usuario:$apr1$xyz…, con la contraseña cifrada en formato bcrypt o MD5 APR1 según la versión. Comprueba los permisos con sudo chmod 640 /etc/nginx/.htpasswd y asigna la propiedad al usuario que ejecuta el servidor web. Y un detalle que conviene no pasar por alto: guarda el archivo fuera del directorio raíz del sitio (en /etc/nginx/ o /etc/apache2/, por ejemplo) para que nadie pueda descargarlo desde el navegador. Si no tienes acceso shell, puedes generarlo temporalmente con herramientas locales, pero créalo luego manualmente en el servidor y nunca dentro de la carpeta pública.

Proteger wp-login.php con autenticación básica en Nginx

Con Nginx la configuración requiere algo de cuidado, porque las directivas de ubicación se heredan de forma particular (y a veces caprichosa). Edita el bloque server de tu sitio —normalmente en /etc/nginx/sites-available/tudominio.conf o /etc/nginx/conf.d/tudominio.conf— y añade un bloque location específico:

Dos detalles técnicos que no puedes saltarte. El primero: usa el operador = para coincidencia exacta, de modo que la protección se aplique solo a wp-login.php y a nada más. El segundo: dentro del bloque location debes repetir la configuración de FastCGI (include y fastcgi_pass), porque al declarar un location con location = pierdes la herencia del bloque que procesa PHP. Ajusta la versión del socket de PHP-FPM (php8.1, php8.2, php8.3) según lo que corra tu servidor.

Verifica la sintaxis con sudo nginx -t y recarga con sudo systemctl reload nginx. Al visitar tudominio.com/wp-login.php debería aparecerte la ventana de autenticación del navegador antes del formulario de WordPress. Si en su lugar ves un error 500 o el navegador intenta descargar el archivo PHP, algo falla en las líneas FastCGI del bloque location: revísalas. Con esto el login queda protegido en Nginx. Vamos ahora con la configuración equivalente en Apache.

Proteger wp-login.php con autenticación básica en Apache

En Apache esto se resuelve con mod_auth_basic, que viene activo en casi cualquier instalación. El primer paso es crear el archivo de contraseñas con htpasswd:

1. Ejecuta htpasswd -c /etc/apache2/.htpasswd usuario (ojo, la opción -c crea el archivo desde cero; cuando añadas más usuarios, déjala fuera).
2. Comprueba que el archivo queda fuera del directorio público del sitio. Lo normal es dejarlo en /etc/apache2/ o /etc/httpd/.
3. Ajusta los permisos: chown www-data:www-data /etc/apache2/.htpasswd && chmod 640 /etc/apache2/.htpasswd.

Luego toca editar el virtualhost de tu sitio. La idea es aplicar la protección solo sobre wp-login.php mediante un bloque FilesMatch o LocationMatch, así el resto de la web queda intacto:

<FilesMatch «wp-login.php»>
AuthType Basic
AuthName «Acceso restringido»
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
</FilesMatch>

Con Apache 2.4 o superior, usa Require valid-user y olvida las viejas directivas Allow/Deny, que ya no pintan nada aquí. Guardas, recargas el servicio con sudo systemctl reload apache2 (httpd en CentOS/RHEL) y pruebas el login.

¿Y si tu hosting no deja tocar el virtualhost? Puedes meter estas mismas directivas en un .htaccess en la raíz de WordPress. Un detalle que suele traicionar a más de uno: AuthUserFile espera una ruta absoluta del sistema de archivos, no una URL.

Errores comunes y cómo verificar que la protección funciona

Aplicada la configuración, es habitual toparse con algún problema. Estos son los más frecuentes:

• Error 403 en lugar del prompt de autenticación: casi siempre significa que el proceso de Nginx o Apache no puede leer el .htpasswd. Revisa propietario y permisos.
• La protección no aparece: puede que entres por HTTPS y solo configuraste el bloque HTTP (o al revés). Aplica la directiva en ambos bloques server, o en el virtualhost del 443.
• Credenciales correctas pero acceso denegado: verifica que generaste el archivo con htpasswd y no con un echo suelto. La contraseña debe ir cifrada, no en texto plano.
• El sitio sigue recibiendo ataques: si tienes CDN o firewall tipo Cloudflare, esos servicios lanzan peticiones directamente al origen y también deben autenticarse; en muchos casos conviene combinar la autenticación básica con un whitelist de IPs.

Para comprobar que todo va bien, desde la terminal: curl -I https://tudominio.com/wp-login.php. Debe devolver un 401 Unauthorized. Después, con credenciales: curl -I -u usuario:contraseña https://tudominio.com/wp-login.php, que debería devolver 200. Y no olvides navegar por el resto del sitio para confirmar que no pide usuario y contraseña en ninguna otra página. Solo el login.

Conclusión: una capa simple que bloquea la mayoría de ataques

Pocas medidas de seguridad dan tanto por tan poco. Exigir una credencial a nivel de servidor, antes de que PHP llegue a enterarse de la petición, corta de raíz la inmensa mayoría de los ataques de fuerza bruta y de diccionario. Y de paso, el servidor respira: menos carga de bots maliciosos golpeando el login.

Eso sí, esta capa no lo cubre todo. Mantén WordPress y sus plugins al día, usa contraseñas fuertes, activa HTTPS y, si puedes, limita el acceso al login por IP. Por separado, cada medida tiene sus agujeros. Juntas, forman una defensa en profundidad difícil de sortear.

Si prefieres no tocar la configuración de tu servidor o te has atascado en alguno de estos pasos, en RedServicio (redservicio.net) encontrarás ayuda profesional especializada en WordPress y administración de servidores para dejar tu sitio protegido en minutos.