En resumen: la forma más eficaz de proteger el área de administración es abrirla solo a redes conocidas: mediante una lista de IP en el servidor web, a través de un VPN con dirección de salida fija o con un segundo inicio de sesión previo. Son importantes una lista completa de todas las direcciones de administración, el tratamiento correcto de proxies y CDN y una prueba desde fuera. El blindaje complementa la autenticación en dos factores y las actualizaciones, pero no las sustituye.
¿Por qué está abierto el backend?
En muchas empresas, los administradores actualizaron PHP la semana pasada y reiniciaron los workers. Quien después revisa los logs de acceso suele constatar otra cosa: la página de inicio de sesión del CMS, la herramienta de base de datos y el panel de hosting reciben llamadas las 24 horas del día desde todo el mundo. Sin embargo, solo las necesitan un puñado de personas del propio equipo.
Cada una de esas direcciones es superficie de ataque. Se prueban formularios de acceso, las herramientas de administración tienen vulnerabilidades propias y los plugins del backend suelen estar peor revisados que el núcleo de un CMS. Si los extraños no pueden ni siquiera alcanzar estas áreas, muchos ataques caen en el vacío antes de empezar.
Dicho con honestidad: frente a PHP2Shell en sí, esto ayuda poco. Las vulnerabilidades están en el intérprete y, según php.net, pueden provocarse sin autenticación a través de páginas PHP públicas. El blindaje del backend es un refuerzo permanente, no un parche de emergencia.
Proteger el área de administración con IP, VPN o segundo inicio de sesión
No existe un único método correcto. Lo decisivo es cómo trabaja su equipo y dónde se ejecuta el sitio web.
| Método | Adecuado para | Límite |
|---|---|---|
| Lista de IP en el servidor web | Oficina con dirección fija, equipos pequeños | Direcciones cambiantes en el teletrabajo, mantenimiento de la lista |
| VPN con dirección de salida fija | Equipos distribuidos, proveedores de servicios | El propio VPN debe estar bien protegido y actualizado |
| Inicio de sesión previo (autenticación HTTP) | Complemento cuando no es posible una dirección fija | Contraseña adicional, solo tiene sentido junto con TLS |
| Certificados de cliente | Pocos dispositivos gestionados de forma fija | La emisión y la revocación de certificados exigen disciplina |
| Nombre de host propio solo en la red interna | Entornos grandes con DNS interno | Reforma de la aplicación; no todos los CMS lo admiten |
En la práctica funciona bien una combinación: autorización solo para el VPN o la red de la empresa, más un segundo inicio de sesión como línea de reserva. El inicio de sesión propiamente dicho en el CMS se mantiene con autenticación en dos factores, como se describe en la guía Autenticación en dos factores para accesos de administración.
¿Qué direcciones pertenecen realmente al backend?
El punto débil más frecuente no es la técnica, sino una lista incompleta. Por eso, proceda en este orden:
- Registrar las páginas de inicio de sesión del CMS o de la tienda, incluidas las direcciones de login alternativas que crean los plugins.
- Buscar herramientas de administración: interfaces de base de datos, gestores de archivos, scripts de instalación, páginas de estado y de monitorización.
- Incluir los paneles de hosting y de servidor, que a menudo se ejecutan en puertos propios.
- Revisar las instancias de prueba y de staging, que con frecuencia usan las mismas credenciales que el sitio en producción.
- Delimitar las interfaces: algunas rutas del backend también las invoca el frontend público, por ejemplo para peticiones Ajax. No debe bloquearlas a ciegas, o se romperán formularios o carritos de compra.
El punto cinco es la razón por la que un blindaje siempre debe probarse. En WordPress, por ejemplo, un archivo de la carpeta de administración se usa también para funciones públicas.
Configuración: lista de IP más segundo inicio de sesión
En Nginx pueden combinarse ambas condiciones. Con satisfy all, una petición debe proceder de una red autorizada y superar además el segundo inicio de sesión. La ruta, las direcciones y el traspaso a PHP son marcadores de posición:
location ^~ /backend/ {
satisfy all;
allow 192.0.2.0/24; # red de la empresa (marcador de posición)
allow 198.51.100.10; # salida del VPN (marcador de posición)
deny all;
auth_basic "Interner Bereich";
auth_basic_user_file /etc/nginx/htpasswd-backend;
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}
La location anidada de PHP es importante: con ^~ ya no se evalúan otras reglas para .php. En Apache se consigue lo mismo con un bloque en el que deben cumplirse ambas condiciones:
<Location "/backend">
AuthType Basic
AuthName "Interner Bereich"
AuthUserFile /etc/apache2/htpasswd-backend
<RequireAll>
Require ip 192.0.2.0/24 198.51.100.10
Require valid-user
</RequireAll>
</Location>
El archivo de contraseñas debe estar fuera del webroot. El segundo inicio de sesión transmite las credenciales en cada petición, por lo que debe usarse únicamente sobre HTTPS.
Antes de cada cambio, mantenga abierta una segunda vía de acceso al servidor, por ejemplo una sesión SSH ya existente. Quien se queda fuera él mismo necesita luego al proveedor de hosting.
Las trampas: CDN, proxy, IPv6 y teletrabajo
Si su sitio web está detrás de un CDN como Cloudflare o de un balanceador de carga, el servidor web solo ve al principio las direcciones de estos. Una lista de IP bloquearía entonces a todos o dejaría pasar a todos. El servidor web debe tomar la dirección real de una cabecera: en Nginx con set_real_ip_from y real_ip_header, en Apache con mod_remoteip.
Rige lo siguiente: acepte la cabecera solo de las direcciones de sus propios proxies. De lo contrario, cualquier visitante puede simular un origen cualquiera. Igual de importante es que el servidor de origen no sea accesible directamente, porque si no puede eludirse el proxy con todas sus reglas. Encontrará indicaciones en Cortafuegos para el servidor web.
Otros dos puntos se pasan por alto a menudo. Si el servidor es accesible por IPv6, también las direcciones IPv6 de su red necesitan una entrada; de lo contrario, los administradores con IPv6 se topan con el bloqueo. Y las conexiones domésticas a internet cambian su dirección con regularidad. Para el teletrabajo y los proveedores externos, un VPN suele ser por ello la solución más estable.
Cómo comprobar que el blindaje funciona
Una regla sin probar no cuenta como implantada. Compruébelo desde una conexión fuera de la red de la empresa, por ejemplo a través de la red móvil:
# Esperado: 403 (bloqueado) o 401 (se exige el segundo inicio de sesión)
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/
# Compruebe también directamente los archivos PHP, no solo el directorio
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/backend/index.php
Después, las mismas llamadas desde la red de la empresa o desde el VPN: allí la página debe ser accesible. A continuación, revise el frontend público, es decir, formularios, búsqueda y carrito. En los logs de los días siguientes, los accesos a las direcciones de administración deberían aparecer casi solo con estado 401 o 403.
Si el área ha estado abierta hasta ahora, merece la pena revisar las cuentas existentes. Cómo encontrar administradores desconocidos lo describe Encontrar cuentas de administrador ajenas en el CMS y el servidor. Como complemento, una protección contra el ensayo masivo de contraseñas ayuda a frenar los ataques; véase Proteger los inicios de sesión de administración frente a la fuerza bruta.
¿Cómo ayuda PHP SOS en concreto?
- Registramos todas las direcciones de administración de sus sitios web, paneles y herramientas y las separamos de las rutas que se necesitan públicamente.
- Elegimos con usted el procedimiento adecuado, según el tamaño del equipo, el teletrabajo y el hosting.
- Aplicamos las reglas en el servidor web, tenemos en cuenta CDN, proxy e IPv6 y mantenemos abierta una vía de retorno.
- Probamos desde fuera y desde dentro y entregamos una breve documentación con las redes autorizadas.
El blindaje de las áreas de administración forma parte de nuestro refuerzo de servidores web PHP.
Preguntas frecuentes
¿No basta con una contraseña segura para el inicio de sesión del CMS?
Una contraseña fuerte y la autenticación en dos factores son obligatorias, pero solo protegen el propio inicio de sesión. Las vulnerabilidades en páginas de login, plugins o herramientas de administración siguen siendo accesibles para cualquiera. Un blindaje a nivel de red o de servidor web consigue que los extraños ni siquiera lleguen hasta ahí.
¿Qué hago si mis empleados tienen direcciones IP cambiantes?
Entonces un VPN con dirección de salida fija suele ser mejor solución que una lista de direcciones sueltas. Todos los administradores se conectan primero al VPN y el servidor web solo autoriza su dirección. Como alternativa, sirve un segundo inicio de sesión previo.
¿Funciona un bloqueo por IP también detrás de Cloudflare o de un balanceador de carga?
Solo si el servidor web toma la dirección real del visitante de una cabecera de confianza y acepta esa cabecera exclusivamente de su propio proxy. De lo contrario, solo ve las direcciones del proxy o se fía de datos falsificados. Además, el servidor de origen no debería ser accesible directamente desde internet.
¿Protege un área de administración blindada frente a PHP2Shell?
Solo de forma muy limitada. Las vulnerabilidades de PHP2Shell están en el intérprete de PHP y pueden explotarse sin autenticación a través de cualquier página PHP pública. Frente a PHP2Shell ayuda la actualización de PHP con el posterior reinicio de todos los workers; el blindaje solo reduce el resto de la superficie de ataque.