Respuesta corta: sí
La respuesta a esta pregunta es un sí inequívoco , y decir lo contrario es completamente irresponsable .
Respuesta larga: un ejemplo del mundo real
Permítame proporcionar un ejemplo muy real, desde mi servidor muy real, donde moverse wp-config.phpfuera de la raíz web específicamente evitó que se capturara su contenido .
El bicho:
Eche un vistazo a esta descripción de un error en Plesk (corregido en 11.0.9 MU # 27):
Plesk restablece el reenvío de subdominio después de sincronizar la suscripción con el plan de alojamiento (117199)
Suena inofensivo, ¿verdad?
Bueno, esto es lo que hice para activar este error:
- Configure un subdominio para redirigir a otra URL (por ejemplo,
site.staging.server.coma site-staging.ssl.server.com).
- Cambió el plan de servicio de la suscripción (por ejemplo, su configuración de PHP).
Cuando hice esto, Plesk restableció el subdominio a los valores predeterminados: sirviendo el contenido de ~/httpdocs/, sin intérpretes (por ejemplo, PHP) activos.
Y no me di cuenta. Por semanas.
El resultado:
- Con
wp-config.phpen la raíz web, una solicitud de /wp-config.phphabría descargado el archivo de configuración de WordPress.
- Con
wp-config.phpfuera de la raíz web, una solicitud para /wp-config.phpdescargar un archivo completamente inofensivo. El wp-config.phparchivo real no se pudo descargar.
Por lo tanto, es obvio que moverse wp-config.phpfuera de la raíz web tiene beneficios de seguridad de buena fe en el mundo real .
Cómo moverse wp-config.phpa cualquier ubicación en su servidor
WordPress buscará automáticamente un directorio sobre su instalación de WordPress para su wp-config.phparchivo, así que si es allí donde lo movió, ¡ya está!
¿Pero qué pasa si lo has movido a otro lugar? Fácil. Cree una nueva wp-config.phpen el directorio de WordPress con el siguiente código:
<?php
/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');
(Asegúrese de cambiar la ruta anterior a la ruta real de su wp-config.phparchivo reubicado ).
Si se encuentra con un problema open_basedir, simplemente agregue la nueva ruta a la open_basedirdirectiva en su configuración de PHP:
open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"
¡Eso es!
Escoger argumentos contrarios
Cada argumento en contra de moverse wp-config.phpfuera de la raíz web depende de suposiciones falsas.
Argumento 1: si PHP está deshabilitado, ya están en
La única forma en que alguien verá ese contenido de [ wp-config.php] es si eluden el intérprete PHP de su servidor ... Si eso sucede, ya está en problemas: tienen acceso directo a su servidor.
FALSO : El escenario que describo anteriormente es el resultado de una configuración incorrecta, no una intrusión.
Argumento 2: Deshabilitar accidentalmente PHP es raro y, por lo tanto, insignificante
Si un atacante tiene acceso suficiente para cambiar el controlador PHP, ya está jodido. Los cambios accidentales son muy raros en mi experiencia, y en ese caso sería fácil cambiar la contraseña.
FALSO : El escenario que describo anteriormente es el resultado de un error en una pieza común de software de servidor, que afecta una configuración de servidor común. Esto es apenas "raro" (y además, la seguridad significa preocuparse por el escenario raro).
WTF : Cambiar la contraseña después de una intrusión difícilmente ayuda si se recogió información confidencial durante la intrusión. Realmente, ¿creemos que WordPress solo se usa para blogs casuales y que los atacantes solo están interesados en la desfiguración? Preocupémonos por proteger nuestro servidor, no solo por restaurarlo después de que alguien entre.
Argumento 3: Denegar el acceso wp-config.phpes suficientemente bueno
Puede restringir el acceso al archivo a través de su configuración de host virtual o
.htaccess, efectivamente, limitar el acceso externo al archivo de la misma manera que lo haría moverse fuera de la raíz del documento.
FALSO : Imagine que los valores predeterminados de su servidor para un host virtual son: no PHP, no .htaccess, allow from all(apenas inusual en un entorno de producción). Si su configuración se restablece de alguna manera durante una operación de rutina, como, por ejemplo, una actualización del panel , todo volverá a su estado predeterminado y estará expuesto.
Si su modelo de seguridad falla cuando la configuración se restablece accidentalmente a los valores predeterminados, necesita más seguridad.
WTF : ¿Por qué alguien recomendaría específicamente menos capas de seguridad? Los autos caros no solo tienen cerraduras; También tienen alarmas, inmovilizadores y rastreadores GPS. Si vale la pena proteger algo, hazlo bien.
Argumento 4: el acceso no autorizado a wp-config.phpno es gran cosa
La información de la base de datos es realmente lo único sensible en [ wp-config.php].
FALSO : Las claves y sales de autenticación se pueden usar en cualquier número de posibles ataques de secuestro.
WTF : Incluso si las credenciales de la base de datos fueran lo único wp-config.php, debería estar aterrorizado de que un atacante las tenga en sus manos.
Argumento 5: moverse wp-config.phpfuera de la raíz web en realidad hace que un servidor sea menos seguro
Todavía tiene que permitir que WordPress acceda [ wp-config.php], por lo que debe expandirse open_basedirpara incluir el directorio sobre la raíz del documento.
FALSO : Suponiendo que wp-config.phpestá adentro httpdocs/, simplemente muévalo ../phpdocs/y configúrelo open_basedirpara incluir solo httpdocs/y phpdocs/. Por ejemplo:
open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"
(Recuerde incluir siempre /tmp/, o su tmp/directorio de usuario , si tiene uno).
Conclusión: los archivos de configuración siempre deben estar siempre ubicados fuera de la raíz web
Si le preocupa la seguridad, se moverá wp-config.phpfuera de su raíz web.