Estoy tratando de asegurar mi blog de WordPress. Leí algunas publicaciones en la web que deberían cambiar table_prefixy ocultar mi wp-config.php. Sin embargo, no lo entiendo? ¿Qué podría hacer un atacante con mi wp-config.php?
Quiero decir que hay mis configuraciones de base de datos, pero el atacante necesita mi, DB_HOSTpor ejemplo, que no es tan fácil de obtener, para conectarse a mi base de datos (en mi caso es:, define('DB_HOST', 'localhost');que el atacante no pudo usar para conectarse a mi base de datos). )
¿O me estoy perdiendo algo?
Realmente aprecio tu respuesta!
Respuestas:
localhostse refiere a la máquina en la que se está ejecutando. Por ejemplo, en mi propio sitio tomjn.com localhost es127.0.0.1como siempre es. Esto no significa que el hacker no sabe dónde se deben conectar, significa que los hackers sustituyelocalhostcontomjn.com.Por supuesto, si tengo un proxy sentado delante, esto no funcionará, pero tenga en cuenta que si el atacante tiene acceso a mi
wp-config.php, ese mismo acceso les permitiría hacer otras cosas en esa máquina.Entonces, el atacante tiene los detalles de su base de datos y puede leer
wp-config.php. Ahora tienen acceso a todo en su base de datos y pueden cambiar cualquier cosa en su base de datos.Dependiendo de la seguridad de su instalación, pueden crear un usuario para sí mismos, iniciar sesión, cargar un complemento a través de zip con un script PHP Shell y comenzar a emitir comandos o usar el sitio como parte de una red de bots.
También tienen sus sales y claves secretas (si no tiene ninguna de estas, malas, malas, malas), por lo que forzar de forma bruta las contraseñas de sus usuarios se vuelve significativamente más fácil. También tienen acceso a sus correos electrónicos.
Basta con decir que conseguir
wp-config.phpes una de las peores cosas que podría suceder. Se pueden hacer muchas más cosas con él, pero llevaría meses escribir cada posible ataque resultante de esto.En el caso de que
wp-config.phpsea adquirido, es probable que lo haya hecho un script de ataque automatizado, no una persona real. Cambie todos sus detalles, restablezca todas las contraseñas y cierre el agujero.fuente
localhostcontomjn.com. > Eso supone que tiene el puerto de la base de datos accesible para el mundo exterior. ¿No estaría a salvo si cerró el puerto en las reglas del firewall y solo permitió que las computadoras de la red local (incluida la computadora que ejecuta wordpress) se conectaran a la base de datos?¿Si solo acepta el acceso a la base de datos desde
localhost(esto no se logra definiendoDB_HOSTcomolocalhost)? No demasiado en sí mismo (el peor de los casos sería un atacante que se hiciera cargo de la cuenta de administrador), pero en combinación con otras vulnerabilidades, podría ser útil que un atacante tenga acceso a su configuración.Credenciales de acceso
Las personas reutilizan sus nombres de usuario y contraseñas. Un atacante verificará si su nombre de usuario y contraseña de la base de datos (o variaciones de ellos) funcionan para su instalación de WordPress, para su proveedor de alojamiento, para su correo electrónico, etc.
Por lo menos, un atacante tiene una idea de qué tipo de contraseñas usa (totalmente al azar, solo minúsculas / números, longitud, etc.).
Tabla de prefijos
Si es posible una inyección SQL, un atacante debe conocer los nombres de las tablas. Dependiendo de la base de datos, esto puede ser muy fácil o puede implicar adivinar. Si implica adivinar, es mejor tener el prefijo de la tabla.
Llaves y sales
Encontré este artículo sugiriendo que realmente no desea que se filtren (básicamente, cualquiera podría hacerse cargo de su cuenta de administrador), aunque no sé cuán actualizado está.
Conjunto de caracteres de base de datos
Algunas inyecciones SQL dependen del conjunto de caracteres, por lo que es bueno que un atacante lo sepa.
Resumen
Si no permite el acceso externo a la base de datos, si no reutiliza las contraseñas y no tiene inyecciones de SQL en ningún lado, la principal preocupación sería la clave y las sales.
fuente
Supongo que está preguntando sobre el acceso de lectura, ya que el acceso de escritura es básicamente acceso para inyectar su propio código para hacer lo que quiera con su sitio.
Su suposición de que la información de la base de datos no es confidencial está mal Supongamos que su sitio está alojado en godaddy. godaddy AFAIK está utilizando un servidor mysql dedicado al que probablemente solo se puede acceder desde sus propios servidores, pero si conozco sus detalles, ¿qué tan difícil es para mí crear una cuenta godaddy y escribir un script que acceda a su base de datos? En el caso de las bases de datos locales, es más difícil de explotar, pero en los servidores de alojamiento compartido puede tener 100 sitios que comparten el servidor con usted, ¿puede confiar en que estén lo suficientemente seguros como para que el Sr. Evil no pueda entrar en ellos y usarlos para atacar su sitio?
fuente