¿Mover wp-config fuera de la raíz web es realmente beneficioso?

135

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.

Ian Dunn
fuente
Realmente no es necesario conectar su elección de respuestas y rechazar todas las demás respuestas, dentro de su pregunta. Como puede ver a continuación, para eso está el sistema de votación stackexchange, para votar las respuestas que tienen sentido para las personas, mientras que los que hacen preguntas deberían usar el mecanismo de "respuesta aceptada" y sus propios votos hacia arriba / hacia abajo.
Kzqai
66
No hago eso para el 99% de las preguntas que hice, pero pensé que era apropiado en este caso específico. Hay 8 respuestas a la pregunta, algunas de las cuales son bastante largas / complejas, y algunas tienen muchos votos a pesar de contener información inexacta o no agregar nada a la conversación. Creo que ofrecer una conclusión semi-autoritativa es útil para las personas que leen el hilo por primera vez. Como siempre, los lectores son libres de tomar su propia decisión; Solo estoy ofreciendo mi opinión como OP.
Ian Dunn
1
@Kzqai: El "sistema de votación de stackexchange" es un proceso democrático, y los participantes a menudo son 1) poco claros en cuanto a lo que el OP está realmente preguntando o tratando de resolver, y 2) sin comprender la validez de cualquier respuesta en particular. Una vez que las respuestas se han introducido y se han emitido los votos, es más que útil que el OP aclare las respuestas que brindaron asistencia. Después de todo, el OP es el único que lo sabe, y desearía que más OP lo hicieran. Sí, la gente "vota las respuestas que tienen sentido para la gente", pero dejemos que el OP tenga la última palabra sobre lo que tiene sentido para él.
Mac

Respuestas:

127

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.

Aaron Adams
fuente
1
Si tienes un error en Apache, Linux o el cerebro del administrador, en cualquier caso, eres un brindis. En su situación, no explica por qué es más probable que ocurra una configuración incorrecta en la raíz del sitio web que en cualquier otro lugar del servidor. Un apache mal configurado probablemente pueda acceder a /../config.php tan fácil como /config.php
Mark Kaplun
1
No eres "tostadas en ningún caso". Es muy probable , e incluso demostrable , que un error provoque que la raíz web se restablezca a sus valores predeterminados, en cuyo caso usted no está "tostado"; su wp-config.phpseguridad sigue siendo segura. Y es extremadamente improbable , hasta el punto de ser esencialmente imposible, que un error podría provocar que la raíz web se restablezca arbitrariamente en el directorio exacto en el que colocó su wp-config.php.
Aaron Adams
1
@IanDunn En realidad, es fácil moverse wp-config.phpa una ubicación arbitraria. He agregado instrucciones a mi respuesta; solo implica crear un ficticio wp-config.phpen el directorio de WordPress que hace referencia a la ubicación del real.
Aaron Adams
3
Esta respuesta es acertada. Mi empresa de alojamiento web tuvo una falla en la matriz de unidades. Cuando todo estuvo dicho y hecho, restauraron el sistema PARCIALMENTE. Resulta que usaron una serie de scripts cPanel / WHM para reconstruir archivos httpd.conf que lo hicieron incorrectamente. Afortunadamente, ya tenía wp-config.php fuera de la raíz del documento, pero si no lo tenía, el contenido estaba allí para tomar. Sí, raro, pero como se señaló, los casos raros son de los que debe preocuparse. Además, afirmar que "la gente de mente simple se perdería" es una mala excusa para tener MENOS seguridad.
Lance Cleveland
1
Ese es un buen punto, Aaron. Todavía estoy un poco escéptico por las razones que he mencionado en este y otros hilos de comentarios, pero me has convencido de que tiene más mérito de lo que pensé originalmente. Por lo menos, si se hace correctamente, no creo que vaya a doler nada. Todavía tengo un problema con el hecho de que la mayoría de las personas que lo promocionan no parecen entender las razones, y la forma en que lo enseñan a menudo llevaría a exponer el directorio sobre httpdocs, pero usted ayudó a abordar esos problemas en tu respuesta.
Ian Dunn
40

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.

chrisguitarguy
fuente
2
Sí, eso es más o menos lo que he estado pensando. Me alegra saber que no soy el único :) Me gustaría dejar la pregunta abierta para otro día o dos en caso de que alguien tenga un contraargumento convincente, pero hasta ahora esta parece ser la respuesta correcta para yo.
Ian Dunn
3
Corrección menor: no hay beneficio de seguridad al mover el archivo wp-config.php fuera de la raíz del documento. Hay otros beneficios, que no están relacionados con la seguridad, y que solo se aplican a configuraciones inusuales.
Otto
44
Solo para desacreditar un posible mito: ¿no es posible, algo podría salir mal del lado del servidor? En cuyo caso, el código php se imprime en la pantalla.
Stephen Harris el
3
@IanDunn Pero las mejores respuestas abogan por sacarlo de esa jerarquía por completo a una separada, que aborde su preocupación por los registros, etc. Esta respuesta no responde al título de su pregunta "se está moviendo ... realmente beneficioso", solo dice otras medidas de seguridad son beneficiosas e intenta tranquilizarlo para que no se preocupe por la seguridad. Todos piensan que su casa es segura hasta que los roben. Después de eso, hacen un mejor trabajo. Algunas personas nunca son robadas, a pesar de que su seguridad es baja, pero eso no significa que sea un buen consejo tener una seguridad más baja.
AndrewC
44
Estos son buenos puntos, pero mi mayor problema con estos es que son argumentos correctivos, no argumentos preventivos. La mayoría de estos hablan de cómo no es un gran problema porque A) asumes que alguien manejó al usuario de db correctamente y B) tienes copias de seguridad. ¿Qué sucede cuando estás usando algo como woocommerce o almacenando información confidencial en tu base de datos? Entonces estás jodido.
Goldentoa11
25

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).

soy yo
fuente
55
Max es la respuesta. +1 a él. Simplemente estoy tratando de extenderlo.
its_me
1
Aahan Krish, has dado en el blanco. Gracias por la adicion.
Max Yudin
Entonces, si usa htaccess para denegar solicitudes HTTP a wp-config.php, ¿eso no logra el mismo resultado que moverlo fuera de la raíz del documento, pero sin exponer registros / copias de seguridad / etc.?
Ian Dunn
44
@IanDunn Depende de cuál sea la raíz del documento: (1) Si WordPress está alojado en un directorio public_html, moverse wp-config.phpfuera del directorio significa que estará en el public_htmldirectorio. En este caso, deberá usar las reglas de htaccess para denegar las solicitudes HTTP a wp-config.php. (2) Si WordPress está instalado directamente en el public_htmldirectorio, un nivel arriba => lo moverá al /home/userdirectorio. En este caso, está bastante seguro ya que el archivo está fuera de la raíz del documento. Todavía puede establecer los permisos del archivo en 600 (o incluso más estrictos 440 o 400).
its_me
@IanDunn Como dije, esta es mi comprensión básica, y no soy un experto en seguridad. :)
its_me
17

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,

Sucuri
fuente
Hola chicos, gracias por agregar sus pensamientos. Creo que ya llegamos a la mayoría de esos puntos en las otras respuestas y sus comentarios. 1) Sí, esto es posible, pero raro; 2) Sí, esto tiene beneficios, pero son mínimos; 3) Sí, esto es posible, pero es poco probable que vuelva a ocurrir ese tipo de vulnerabilidad, y protegerse contra él es algo así como jugar whac-a-mole, o hacer que la gente se quite los zapatos en los aeropuertos porque un burro escondió una bomba en su zapato una vez. Es reaccionario y es poco probable que tenga beneficios futuros.
Ian Dunn el
En las diversas discusiones, la pregunta se refinó desde "¿Hay algún beneficio?" a "Ok, hay algunos beneficios, pero ¿superan los riesgos?" El principal riesgo al que me refiero es el hecho de que tiene que expandir el alcance de openbase_dir para permitir que PHP acceda a los scripts fuera de la raíz web. Muchas configuraciones de alojamiento, incluidas las que usan Plesk, que es mucho, almacenan registros, copias de seguridad, áreas FTP privadas que se supone que están aisladas de la raíz web, etc., en el directorio que se encuentra sobre la raíz web. Por lo tanto, dar acceso PHP a ese directorio puede ser una vulnerabilidad grave.
Ian Dunn el
15

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.

Max Yudin
fuente
44
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. A la luz de esas cosas, ¿todavía cree que vale la pena el riesgo de exponer registros / copias de seguridad / etc. debido al open_basediralcance ampliado ?
Ian Dunn
1
Nunca he tenido -rwxacceso a directorios superiores a los public_htmlque nunca conocí open_basedir. Mis registros están en un directorio separado, así que las copias de seguridad lo hacen. Creo que eso es lo que tienen todos los hosts compartidos.
Max Yudin
Los anfitriones varían enormemente; No hay una estructura de directorio estándar. Plesk (uno de los paneles de control más populares para hosts compartidos) coloca registros en /var/www/vhosts/example.com/statistics/logs y la raíz del documento es /var/www/vhosts/example.com/httpdocs. Mover wp-config.php a /var/www/vhosts/example.com/wp-config.php requeriría dar acceso a los scripts a todo el directorio example.com.
Ian Dunn
Solo por curiosidad, ¿dónde están almacenados sus registros y copias de seguridad, si no están en el directorio del dominio? ¿Se accede a ellos a través de un panel de control o algo así?
Ian Dunn
1
Sí, a través de un panel de control.
Max Yudin
8

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
Miguel
fuente
Hola Michael, gracias por compartir eso. Sin embargo, ¿lo has probado en un entorno real para verificar que funciona? Creo que la open_basedirDirectiva tiene todo un árbol , por lo que con el fin de acceder /root/securea /root/html, usted tiene que fijar open_basedira /root.
Ian Dunn
Para que su idea funcione, creo que necesitaría configurar la estructura de directorios como /root/httpdocs/config/accessible, donde se httpdocsguardan registros, copias de seguridad, etc. configcontiene wp-config.phpy accessiblecontiene WordPress y todo el contenido. Tendría que modificar la configuración de vhost, etc. para reasignar la raíz del documento accessible. Sin embargo, no veo ningún beneficio con solo negar las solicitudes HTTP a wp-config en la configuración predeterminada.
Ian Dunn
1
De acuerdo con php.net/manual/en/ini.core.php#ini.open-basedir : "En Windows, separe los directorios con un punto y coma. En todos los demás sistemas, separe los directorios con dos puntos. Como un módulo de Apache, Las rutas open_basedir de los directorios principales ahora se heredan automáticamente ". Por lo tanto, puede configurar varios directorios, sin necesidad de que estén en un solo árbol.
Michael
Acabo de probar eso y parece que tienes razón. Sin embargo, todavía no estoy seguro de qué beneficio de seguridad tiene esto sobre simplemente negar el acceso al archivo a través de Apache.
Ian Dunn
@IanDunn se dirigió bien en la respuesta de Aaron Adams
AndrewC
4

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).

Ralf912
fuente
Esta respuesta no aborda directamente la pregunta. Cualquier autor de complementos puede tener un día de campo con WordPress si lo convencen de instalar su código y tienen intenciones maliciosas. No es diferente a instalar voluntariamente un virus en su sistema. Este argumento para no mover wp-config.php no tiene sentido. Esto es como decir que instalar deliberadamente un coche bomba en su automóvil hace que la configuración de la alarma del automóvil sea inútil. ¿Técnicamente cierto pero WTF?
Lance Cleveland
2
No, no tiene sentido. La pregunta es: ¿puedo proteger la cuenta de la base de datos ocultando wp-config.php? Y la respuesta es clara: No. Es lo mismo que si pregunta '¿Puedo proteger mi automóvil contra los coches bomba con una alarma de automóvil?' No hay otro beneficio al ocultar su configuración de wp para proteger el acceso a la base de datos o el acceso ftp. Ambos están en el alcance global. Estoy seguro de que hay más formas para que los atacantes tengan acceso a variables globales sin inyectar código.
Ralf912
No veo "¿puedo proteger la cuenta de la base de datos ocultando wp-config.php" en la pregunta original. La pregunta original era "¿tiene sentido mover el wp-config.php". La respuesta es absolutamente sí, OMI. Es como preguntar si debe cerrar la puerta cuando salga. Decir "alguien puede romper fácilmente una ventana y entrar de todos modos, entonces, ¿por qué molestarse" no responde el punto fundamental de la pregunta. En mi opinión, la pregunta que se hizo fue: "¿Vale la pena el esfuerzo adicional para mover wp-config.php? ¿CUALQUIER beneficio al hacerlo?". Si. Por lo menos, mantiene alejados a los hackers perezosos.
Lance Cleveland
2
Una de las mejores prácticas de seguridad más comunes ... Se perdió un punto muy (muy, muy) importante: ¿en qué está interesado un atacante? Y es que no , ¿cómo una decoración cuidada su wp-config.php. Un atacante está interesado en los valores que definió en su wp-config. Agarrando su ejemplo con la puerta de entrada: Ocultar su wp-config es lo mismo que si cerrara la puerta de entrada, pero almacenara todo su oro sin protección en el jardín. Todos los valores definidos en wp-config están definidos globalmente . Por lo tanto, todos son accesibles fuera de wp-config. Incluso si oculta su wp-config, los valores aún están presentes.
Ralf912
1
Creo que aquellos que argumentan a favor de moverlo están tratando de proteger contra escenarios donde wp-config.php podría mostrarse en texto plano a través de una solicitud HTTP, en lugar de escenarios donde podría estar expuesto a otro código PHP que se ejecuta en el host.
Ian Dunn
-1

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.

Emzo
fuente
8
Lo tiene configurado en la raíz del documento, no fuera de él, por lo que no es relevante para esta pregunta. La técnica sobre la que se formuló la pregunta especifica que mueva wp-config.phpun directorio sobre la raíz del documento del vhost , no solo un directorio sobre la carpeta de instalación de WordPress. El objetivo es sacarlo de la carpeta que puede leer las solicitudes HTTP.
Ian Dunn