Italiano
Română
Русский¿Es realmente beneficioso mover wp-config fuera del directorio raíz web?
Una de las prácticas de seguridad más comunes en estos días parece ser mover wp-config.php un directorio más arriba que el directorio raíz del vhost. Nunca he encontrado una buena explicación para esto, pero supongo que es para minimizar el riesgo de que un script malicioso o infectado dentro del directorio web pueda leer la contraseña de la base de datos.
Sin embargo, aún debes permitir que WordPress acceda a él, por lo que necesitas expandir open_basedir para incluir el directorio superior al directorio raíz. ¿No anula esto todo el propósito y además potencialmente expone los logs del servidor, copias de seguridad, etc. a los atacantes?
¿O la técnica solo intenta prevenir una situación donde wp-config.php se mostraría como texto plano a cualquiera que solicite http://example.com/wp-config.php, en lugar de ser procesado por el motor PHP? Esto parece ser una ocurrencia muy rara, y no compensaría las desventajas de exponer logs/backups/etc a peticiones HTTP.
¿Quizás es posible moverlo fuera del directorio raíz en algunas configuraciones de hosting sin exponer otros archivos, pero no en otras configuraciones?
Conclusión: Después de mucho debate sobre este tema, han surgido dos respuestas que creo que deberían considerarse las autorizadas. Aaron Adams presenta un buen argumento a favor de mover wp-config, y chrisguitarguy presenta un buen argumento en contra. Estas son las dos respuestas que deberías leer si eres nuevo en el hilo y no quieres leer todo el contenido. Las otras respuestas son redundantes o inexactas.
Si tienes un error en Apache, Linux o en el cerebro del administrador, estás perdido de cualquier manera. En tu escenario no logras explicar por qué es más probable que ocurra una mala configuración en la raíz del sitio web que en cualquier otro lugar del servidor. Un Apache mal configurado probablemente podría acceder a /../config.php tan fácilmente como a /config.php
Mark Kaplun
No estás "perdido de cualquier manera". Es muy probable, e incluso demostrable, que un error resultaría en que la raíz web se restablezca a su valor predeterminado, en cuyo caso no estás "perdido" – tu wp-config.php permanece seguro. Y es extremadamente improbable – tanto que esencialmente es imposible – que un error resulte en que la raíz web se restablezca arbitrariamente exactamente al directorio donde colocaste tu wp-config.php.
Aaron Adams
¿Qué tan probable es este tipo de error? No soy un experto en seguridad, pero nunca he escuchado que este vector de ataque se utilice en la práctica. Estoy en contra de recomendar este método porque cuando necesites mantener tu sitio, no sabrás dónde está tu wp-config y probablemente invalidará la mayoría de los tutoriales que tocan ese archivo de alguna manera. Tú, yo y el resto de los comentaristas aquí descubriremos qué pasó, pero para personas con menos experiencia será un gran y prolongado momento de WTF.
Mark Kaplun
@MarkKaplun "La gente que no lee Stack Exchange podría confundirse" es un argumento bastante pobre en contra de recomendar una práctica de seguridad en Stack Exchange. Cuando más personas comprendan los peligros reales de dejar archivos de configuración sensibles dentro del directorio raíz web, más personas moverán esos archivos fuera del directorio raíz, y más tutoriales de WordPress se escribirán para ayudar al usuario a ubicar el archivo wp-config.php. Si crees que la conveniencia es más importante que la seguridad, esa es tu opinión; solo deja claro, entonces, que estás recomendando que los usuarios prioricen la conveniencia sobre la seguridad.
Aaron Adams
Hola Aaron, gracias por tu respuesta reflexiva y detallada. Tienes razón en que simplemente cambiar la contraseña después de una intrusión no es suficiente. Sin embargo, todavía no me convence tu anécdota sobre Plesk. Definitivamente es un problema, pero no creo que mover wp-config sea la solución adecuada para ese problema. Lo mismo aplica para la configuración de vhost que se reinicia, etc. Si tu aplicación necesita suficiente seguridad como para preocuparte por ese tipo de vulnerabilidades, entonces realmente necesitas abordarlas de una manera más directa. Por ejemplo, no uses Plesk, porque siempre será vulnerable; asegúrate de que tu configuración de vhost sea segura por defecto...
Ian Dunn
Sí, eso es básicamente lo que he estado pensando. Me alegra saber que no soy el único :) Me gustaría dejar la pregunta abierta uno o dos días más por si alguien tiene un contraargumento convincente, pero hasta ahora esta parece ser la respuesta correcta para mí.
Ian Dunn
Pequeña corrección: No hay ningún beneficio de seguridad al mover el archivo wp-config.php fuera del directorio raíz del documento. Hay otros beneficios, que no están relacionados con la seguridad, y que solo aplican en configuraciones inusuales.
Otto
Buen apunte. Editado.
chrisguitarguy
Solo para desmentir un posible mito - ¿no es posible que algo salga mal del lado del servidor, en cuyo caso el código php se imprima en la pantalla?
Stephen Harris
Claro. Si mod_php no está funcionando o los archivos PHP no se pasan al intérprete de PHP, es posible. Si estás ejecutando una configuración FCGI, puede ocurrir lo mismo si los archivos PHP no se pasan al proceso fcgi para su interpretación. Ambos casos apuntan a problemas bastante grandes que no son probables que ocurran, sin embargo.
chrisguitarguy
Max tiene la respuesta. +1 para él. Simplemente estoy tratando de ampliarla.
its_me
Aahan Krish, has dado en el blanco. Gracias por el aporte.
Max Yudin
Entonces, si usas htaccess para denegar solicitudes HTTP a wp-config.php, ¿no se logra el mismo resultado que moverlo fuera del directorio raíz del documento, pero sin exponer logs/backups/etc?
Ian Dunn
@IanDunn Depende de cuál sea la raíz del documento— (1) Si WordPress está alojado en un directorio dentro de public_html, mover wp-config.php fuera del directorio significa que estará en el directorio public_html. En este caso, tendrás que usar reglas htaccess para denegar las solicitudes HTTP a wp-config.php. (2) Si WordPress está instalado directamente bajo el directorio public_html, un nivel arriba => lo estarás moviendo al directorio /home/usuario. En este caso estarás bastante seguro ya que el archivo está fuera de la raíz del documento. Aún puedes establecer los permisos del archivo en 600 (o incluso más restrictivos 440 o 400).
its_me
@IanDunn Como dije, este es mi entendimiento básico, y no soy un experto en seguridad. :)
its_me
Hola chicos, gracias por compartir sus opiniones. Creo que ya hemos tocado 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 ese tipo de vulnerabilidad es poco probable que vuelva a ocurrir, y protegerte contra ella es como jugar al "whac-a-mole", o hacer que la gente se quite los zapatos en los aeropuertos porque algún idiota escondió una bomba en su zapato una vez. Es reactivo y poco probable que tenga beneficios futuros.
Ian Dunn
En las diversas discusiones, la pregunta se refinó de "¿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 tienes que expandir el alcance de openbase_dir para permitir que PHP acceda a scripts fuera del directorio raíz web. Muchas configuraciones de hosting -- incluyendo aquellas que usan Plesk, que son muchas -- almacenan logs, backups, áreas FTP privadas que se supone deben estar aisladas del directorio raíz web, etc. en el directorio superior al raíz web. Por lo tanto, darle acceso a PHP a ese directorio puede ser una vulnerabilidad seria.
Ian Dunn
@IanDunn ¿desde cuándo la rareza de un evento ha sido un contraargumento válido para no tomar una medida de seguridad preventiva que aborde tal evento improbable? Tu punto sobre dónde PHP puede abrir archivos puede abordarse hoy en día mediante el endurecimiento de systemd, por cierto. Todo el punto de la seguridad en TI es que los atacantes tienen infinitas rutas de incursión a su disposición, mientras que los defensores solo pueden defenderse contra vectores de ataque conocidos. Por lo tanto, es costumbre combinar tantas medidas preventivas como sea factible para proporcionar una red de seguridad, en lugar de depender de un solo nudo.
0xC0000022L
Si un atacante tiene suficiente acceso para cambiar el manejador de PHP, ya estás en problemas. Los cambios accidentales son muy raros en mi experiencia, y en ese caso sería fácil cambiar la contraseña. Teniendo en cuenta esto, ¿sigues pensando que vale la pena el riesgo de exponer registros/copias de seguridad/etc. debido al alcance ampliado de open_basedir?
Ian Dunn
Nunca he tenido acceso -rwx a directorios superiores a public_html, así que nunca estuve familiarizado con open_basedir. Mis registros están en un directorio separado, igual que las copias de seguridad. Creo que eso es lo que tienen todos los hosts compartidos.
Max Yudin
Los hosts varían mucho; no hay una estructura de directorios estándar. Plesk (uno de los paneles de control más populares para hosts compartidos) coloca los registros en /var/www/vhosts/example.com/statistics/logs y la raíz del documento está en /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 se almacenan tus 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
Sí, a través de un panel de control.
Max Yudin
Hola Michael, gracias por compartir eso. ¿Lo has probado en un entorno real para verificar que funciona? Creo que la directiva open_basedir toma un árbol completo, así que para acceder a /root/secure desde /root/html, tendrías que configurar open_basedir como /root.
Ian Dunn
Para que tu idea funcione, creo que necesitarías configurar la estructura de directorios como /root/httpdocs/config/accessible, donde httpdocs contenga logs, backups, etc; config contenga wp-config.php, y accessible contenga WordPress y todo el contenido. Tendrías que modificar la configuración del vhost, etc. para reasignar el document root a accessible. Aunque no veo ningún beneficio sobre simplemente denegar las peticiones HTTP a wp-config en la configuración predeterminada.
Ian Dunn
Según http://www.php.net/manual/en/ini.core.php#ini.open-basedir: "En Windows, separa los directorios con punto y coma. En otros sistemas, separa los directorios con dos puntos. Como módulo de Apache, las rutas open_basedir de los directorios padres ahora se heredan automáticamente." Así que puedes configurar múltiples directorios, no es necesario que estén en un único árbol.
Michael
Acabo de probarlo y parece que tienes razón. Aún no estoy seguro de qué beneficio de seguridad tiene esto sobre simplemente denegar el acceso al archivo a través de Apache.
Ian Dunn
@IanDunn lo abordó bien en la respuesta de Aaron Adams
AndrewC
Esta respuesta no aborda directamente la pregunta. Cualquier autor de plugins puede tener un día de campo con WordPress si te convence de instalar su código y tiene intenciones maliciosas. No es diferente a instalar voluntariamente un virus en tu sistema. Este argumento para no mover wp-config.php no tiene sentido. Es como decir que instalar voluntariamente una bomba en tu auto hace que activar la alarma del auto sea inútil. Técnicamente cierto, pero ¡¿qué demonios?!
Lance Cleveland
No, no carece de sentido. La pregunta es: ¿Puedo proteger la cuenta de la base de datos ocultando wp-config.php? Y la respuesta es claramente: No. Es lo mismo que preguntar: "¿Puedo proteger mi auto contra bombas con una alarma?" No hay otro beneficio al ocultar tu wp-config más allá de proteger el acceso a la base de datos o FTP. Ambos están en el ámbito global. Estoy seguro de que hay más formas para que los atacantes accedan 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 wp-config.php?". La respuesta es absolutamente sí, en mi opinión. Es como preguntar si deberías cerrar con llave la puerta de entrada cuando sales. Decir "alguien puede romper fácilmente una ventana y entrar de todos modos, así que ¿para qué molestarse?" no responde al punto fundamental de la pregunta. En mi opinión, la pregunta era: "¿Vale la pena el esfuerzo adicional de mover wp-config.php? ¿Hay ALGÚN beneficio al hacerlo?". Sí. Al menos mantiene alejados a los hackers perezosos.
Lance Cleveland
Una de las mejores prácticas de seguridad más comunes... Te perdiste un punto muy (muy, muy) importante: ¿En qué está interesado un atacante? Y no es cómo hayas estilizado tu wp-config.php. Un atacante está interesado en los valores que has definido en tu wp-config. Tomando tu ejemplo con la puerta principal: Ocultar tu wp-config es lo mismo que si cerraras con llave tu puerta principal, pero dejaras todo tu oro desprotegido en el jardín. Todos los valores definidos en el wp-config son definidos globalmente. Por lo tanto, son todos accesibles fuera del wp-config. Incluso si ocultas tu wp-config, los valores siguen presentes.
Ralf912
Creo que aquellos que argumentan a favor de moverlo están intentando 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 exponerse a otro código PHP ejecutándose en el host.
Ian Dunn
De hecho, es algo muy bueno agregar una respuesta a una pregunta antigua, incluso hay una insignia por ello. WPSE está diseñado para ser un repositorio de conocimiento, más que un foro.
Ian Dunn
Lo tiene configurado en la raíz del documento, no fuera de ella, por lo que no es relevante para esta pregunta. La técnica sobre la que se pregunta especifica que debes mover wp-config.php un directorio por encima de la raíz del documento del vhost, no solo un directorio por encima de la carpeta de instalación de WordPress. El objetivo principal es sacarlo de la carpeta que puede ser leída por solicitudes HTTP.
Ian Dunn