Una de las mejores prácticas de seguridad más comunes en estos días parece estar moviendo wp-config.phpun directorio más alto que la raíz del documento del vhost . Realmente nunca he encontrado una buena explicación para eso, pero supongo que es para minimizar el riesgo de que un script malintencionado o infectado dentro del webroot lea la contraseña de la base de datos.

Pero, aún debe dejar que WordPress acceda a él, por lo que debe expandirse open_basedirpara incluir el directorio sobre la raíz del documento. ¿Acaso eso no acaba con todo el propósito y también expone potencialmente los registros del servidor, las copias de seguridad, etc. a los atacantes?

¿O la técnica solo está tratando de evitar una situación en la wp-config.phpque se mostrará como texto sin formato a cualquiera que lo solicite http://example.com/wp-config.php, en lugar de ser analizado por el motor PHP? Parece una ocurrencia muy rara, y no superaría las desventajas de exponer registros / copias de seguridad / etc. a solicitudes HTTP.

¿Quizás es posible moverlo fuera de la raíz del documento en algunas configuraciones de hosting sin exponer otros archivos, pero no en otras configuraciones?

Conclusión: Después de mucho ir y venir sobre este tema, han surgido dos respuestas que creo que deberían considerarse las autorizadas. Aaron Adams hace un buen caso a favor de mover wp-config, y chrisguitarguy hace un buen caso en su contra . Esas son las dos respuestas que debes leer si eres nuevo en el hilo y no quieres leer todo. Las otras respuestas son redundantes o inexactas.

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:

1. Configure un subdominio para redirigir a otra URL (por ejemplo, site.staging.server.coma site-staging.ssl.server.com).
2. 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.

Lo más importante es que wp-config.phpcontiene información confidencial: el nombre de usuario / contraseña de su base de datos, etc.

Entonces, la idea: muévala fuera de la raíz del documento, y no tendrá que preocuparse por nada. Un atacante nunca podrá acceder a ese archivo desde una fuente externa.

Aquí está el problema, sin embargo: en wp-config.phprealidad nunca imprime nada en la pantalla. Solo define varias constantes que se utilizan durante la instalación de WP. Por lo tanto, la única forma en que alguien verá ese contenido de ese archivo es si eluden el intérprete PHP de su servidor: obtienen el .phparchivo para representarlo como texto sin formato. Si eso sucede, ya está en problemas: tienen acceso directo a su servidor (y probablemente permisos de root) y pueden hacer lo que quieran.

Voy a seguir adelante y decir que no hay ningún beneficio en wp-configsalir de la raíz del documento desde una perspectiva de seguridad , por las razones anteriores y estas:

1. Puede restringir el acceso al archivo a través de su configuración de host virtual o .htaccess, limitando efectivamente el acceso externo al archivo de la misma manera que moverse fuera de la raíz del documento
2. Puede asegurarse de que los permisos del archivo sean estrictos wp-configpara evitar que cualquier usuario sin privilegios suficientes lea el archivo incluso si obtiene acceso (limitado) a su servidor a través de SSH.
3. Su información confidencial, la configuración de la base de datos, solo se usa en un solo sitio. Entonces, incluso si un atacante obtuviera acceso a esa información, el único sitio al que afectaría sería la instalación de WordPress a la wp-config.phpque pertenece el archivo. Más importante aún, ese usuario de la base de datos solo tiene permisos para leer y escribir en la base de datos de la instalación de WP y nada más, no tiene acceso para otorgar permisos a otros usuarios. En otras palabras, si un atacante obtiene acceso a su base de datos, simplemente se trata de restaurar desde una copia de seguridad (ver punto 4) y cambiar el usuario de la base de datos.
4. Hace copias de seguridad a menudo. A menudo es un término relativo: si publica 20 artículos todos los días, es mejor que haga una copia de seguridad todos los días o cada pocos días. Si publica una vez por semana, es probable que sea suficiente hacer una copia de seguridad una vez por semana.
5. Tiene su sitio bajo control de versiones ( como este ), lo que significa que incluso si un atacante obtuvo acceso, puede detectar fácilmente los cambios de código y revertirlos. Si un atacante tiene acceso wp-config, probablemente se haya metido con algo más.
6. La información de la base de datos es realmente la única información confidencial wp-config, y debido a que tienes cuidado al respecto (ver puntos 3 y 4), no es un gran problema. Las sales y tal se pueden cambiar en cualquier momento. Lo único que sucede es que invalida las cookies de los usuarios registrados.

Para mí, wp-configsalir de la raíz del documento apesta a seguridad por la oscuridad, que es en gran medida un hombre de paja.

Creo que Max es una respuesta bien informada, y ese es un lado de la historia. El Codex de WordPress tiene más consejos :

Además, asegúrese de que solo usted (y el servidor web) puedan leer este archivo (generalmente significa un permiso de 400 o 440).

Si usa un servidor con .htaccess, puede poner esto en ese archivo (en la parte superior) para denegar el acceso a cualquiera que esté navegando por él:

<files wp-config.php>
order allow,deny
deny from all
</files>

Tenga en cuenta que configurar el permiso 400 o 440 en wp-config.php puede evitar que los complementos lo escriban o lo modifiquen. Un caso genuino, por ejemplo, sería el almacenamiento en caché de complementos (W3 Total Cache, WP Super Cache, etc.) En ese caso, elegiría 600 (el permiso predeterminado para los archivos en el /home/userdirectorio).

Alguien nos pidió que brillemos, y responderé aquí.

Sí, existen beneficios de seguridad al aislar su wp-config.php del directorio raíz de su sitio.

1- Si su controlador PHP se rompe o modifica de alguna manera, su información de base de datos no será expuesta. Y sí, vi que esto sucedió varias veces en hosts compartidos durante las actualizaciones del servidor. Sí, el sitio estará roto durante ese período, pero sus contraseñas estarán intactas.

2- Las mejores prácticas siempre recomiendan aislar los archivos de configuración de los archivos de datos. Sí, es difícil hacerlo con WordPress (o cualquier aplicación web), pero subirlo hace un poco de aislamiento.

3- Recuerde la vulnerabilidad PHP-CGI, donde cualquiera podría pasar los? -S a un archivo y ver la fuente. http://www.kb.cert.org/vuls/id/520827

Al final, esos son pequeños detalles, pero ayudan a minimizar el riesgo. Especialmente si se encuentra en un entorno compartido, donde cualquiera puede acceder a su base de datos (todo lo que necesitan es un usuario / pase).

Pero no permita que pequeñas distracciones (optimizaciones prematuras) se pongan por delante de lo que es realmente necesario para que un sitio esté bien protegido:

1- Mantenlo siempre actualizado

2- Usa contraseñas seguras

3- Restringir el acceso (a través de permisos). Tenemos una publicación al respecto aquí:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

Gracias,

Definitivamente sí.

Cuando mueve wp-config.php fuera del directorio público, lo protege de la lectura usando el navegador cuando el controlador php se modifica maliciosamente (¡o accidentalmente!).

Es posible leer su nombre de usuario / contraseña de base de datos cuando el servidor apenas está infectado por un error del administrador cojo. Cargue una multa al administrador y obtenga un servidor host mejor y más confiable. Aunque eso puede ser más caro.

Solo quiero aclarar, por razones de argumento, que mover su archivo wp_config.php no significa necesariamente que tenga que moverlo solo al directorio padre. Digamos que tiene una estructura como / root / html, donde html contiene la instalación de WP y todo su contenido HTML. En lugar de mover wp_config.php a / root, puede moverlo a algo como / root / secure ... que está fuera del directorio html y tampoco en el directorio raíz del servidor. Por supuesto, deberá asegurarse de que php también se pueda ejecutar en esta carpeta segura.

Como WP no se puede configurar para buscar wp_config.php en una carpeta hermana como / root / secure, debe dar un paso adicional. Dejé wp_config.php en / root / html, corté las partes sensibles (inicio de sesión de la base de datos, sal, prefijo de tabla) y las moví a un archivo separado llamado config.php. Luego agrega el includecomando PHP a su wp_config.php, así:include('/home/content/path/to/root/secure/config.php');

Esto es esencialmente lo que he hecho en mi configuración. Ahora, en base a la discusión anterior, todavía estoy evaluando si es necesario o incluso una buena idea. Pero solo quería agregar que la configuración anterior es posible. No expone sus copias de seguridad y otros archivos raíz, y mientras la carpeta segura no esté configurada con su propia URL pública, no se puede navegar.

Además, puede limitar el acceso a la carpeta segura creando un archivo .htaccess allí con:

order deny,allow
deny from all
allow from 127.0.0.1

Hay muchos temas y complementos mal escritos que permiten a los atacantes inyectar código (recuerde el problema de seguridad con Timthumb). Si sería un atacante, ¿por qué debería buscar el wp-config.php? Simplemente inyecte este código:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Puedes intentar ocultar tu wp-config.php. Mientras WordPress haga que toda la información confidencial sea accesible globalmente, no tiene ningún beneficio ocultar el wp-config.php.

La parte mala de wp-config.php no es que contenga datos confidenciales. Lo malo es definir los datos confidenciales como una constante global accesible.

Actualizar

Quiero aclarar los problemas define()y por qué es una mala idea definir datos confidenciales como una constante global.

Hay muchas formas de atacar un sitio web. La inyección de script es solo una forma de atacar un sitio web.

Suponiendo que el servidor tiene una vulnerabilidad que permite que un atacante acceda a un volcado de memoria. El atacante encontrará en el volcado de memoria todos los valores de todas las variables. Si define una constante accesible global, debe permanecer en la memoria hasta que finalice el script. Al crear una variable en lugar de una constante, existe una buena posibilidad de que el recolector de basura sobrescriba (o libere) la memoria después de que la variable ya no sea necesaria.

Una mejor manera de proteger los datos confidenciales es eliminarlos inmediatamente después de usarlos:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

Después de usar los datos confidenciales, la asignación a nullsobrescribirá los datos en la memoria. Un atacante debe obtener el volcado de memoria justo en el momento en que $db_concontiene los datos confidenciales. Y eso es muy poco tiempo en el ejemplo anterior (si la clase Database_Handler no guarda una copia).

Además de los beneficios de seguridad, también le permite mantener su instancia de WordPress bajo control de versión mientras mantiene los archivos principales de WordPress como submódulo / externo. Así es como Mark Jaquith ha configurado su proyecto WordPress-Skeleton. Ver https://github.com/markjaquith/WordPress-Skeleton#assumptions para más detalles.