Estou tentando proteger meu blog wordpress. Eu li algumas postagens na web que eu deveria mudar table_prefixe ocultar wp-config.php. No entanto, eu não entendi? O que um atacante poderia fazer com o meu wp-config.php?
Quero dizer, existem minhas configurações de banco de dados, mas o invasor precisa das minhas, DB_HOSTpor exemplo, o que não é tão fácil de obter, para conectar-se ao meu banco de dados (no meu caso é:, define('DB_HOST', 'localhost');que o invasor não pode usar para se conectar ao meu banco de dados )
Ou estou sentindo falta de algo?
Eu realmente aprecio sua resposta!
Respostas:
localhostrefere-se à máquina em que está sendo executada. Por exemplo, no meu próprio site tomjn.com localhost é127.0.0.1como sempre é. Isso não significa que o hacker não sabe onde se conectar, isso significa que os substitui hackerslocalhostcomtomjn.com.É claro que se eu tiver um proxy na frente, isso não funcionará, mas lembre-se de que, se o invasor tiver acesso ao meu
wp-config.php, esse mesmo acesso permitiria que ele fizesse outras coisas nessa máquina.Então agora o invasor tem os detalhes do seu banco de dados e pode ler
wp-config.php. Agora eles têm acesso a tudo no seu banco de dados e podem mudar qualquer coisa no seu banco de dados.Dependendo da segurança de sua instalação, eles podem criar um usuário para eles mesmos, fazer login, fazer upload de um plug-in via zip com um script PHP Shell e começar a emitir comandos ou usar o site como parte de uma rede de bots.
Eles também têm seus sais e chaves secretas (se você não tiver nenhum desses itens, muito ruim ou muito ruim), portanto, forçar brutalmente as senhas dos usuários se torna significativamente mais fácil. Eles também têm acesso aos seus e-mails.
Basta dizer que conseguir
wp-config.phpé uma das piores coisas que podem acontecer. Muito mais coisas podem ser feitas com isso, mas levaria meses para digitar todos os ataques possíveis resultantes disso.Caso você
wp-config.phpseja adquirido, é provável que um script de ataque automatizado tenha feito isso, não uma pessoa real. Altere todos os seus detalhes, redefina todas as senhas e feche o buraco.fonte
localhostcomtomjn.com. > Supondo que você tenha a porta do banco de dados acessível para o mundo externo. Você não estaria seguro se fechasse a porta nas regras do firewall, permitindo apenas que os computadores da rede local (incluindo o próprio computador executando o wordpress) se conectassem ao banco de dados?Se você aceitar apenas o acesso ao banco de dados
localhost(isso não é possível definindoDB_HOSTcomolocalhost)? Não muito por si só (o pior caso seria um invasor assumir a conta de administrador), mas em combinação com outras vulnerabilidades pode ser útil para um invasor ter acesso à sua configuração.Credenciais de login
As pessoas reutilizam seus nomes de usuário e senhas. Um invasor verificará se o nome de usuário e a senha do banco de dados (ou variações deles) funcionam na instalação do wordpress, no hoster, no email, etc.
No mínimo, um invasor tem uma idéia de que tipo de senha você usa (totalmente aleatório, apenas letras minúsculas / números, tamanho, etc).
Prefixo da tabela
Se for possível uma injeção de SQL, o invasor deve saber os nomes da tabela. Dependendo do banco de dados, isso pode ser muito fácil ou pode envolver adivinhações. Se envolver adivinhação, é melhor ter o prefixo da tabela.
Chaves e sais
Encontrei este artigo sugerindo que você realmente não deseja que eles vazem (basicamente, qualquer um pode assumir sua conta de administrador), embora eu não saiba como está atualizado.
Conjunto de caracteres do banco de dados
Algumas injeções de SQL dependem do conjunto de caracteres; portanto, é bom que um invasor saiba disso.
Sumário
Se você não permitir acesso externo ao banco de dados, se você não reutilizar senhas e se você não tiver nenhuma injeção de SQL em nenhum lugar, a principal preocupação seria a chave e os sais.
fonte
Suponho que você esteja perguntando sobre o acesso de leitura, pois o acesso de gravação é basicamente o acesso para injetar seu próprio código e fazer o que ele quiser no seu site.
Sua suposição de que as informações do banco de dados não são confidenciais está errada. Vamos supor que seu site esteja hospedado no godaddy. godaddy AFAIK está usando servidores mysql dedicados que provavelmente só podem ser acessados a partir de seus próprios servidores, mas se eu souber dos seus detalhes, é difícil criar uma conta godaddy e escrever um script que acesse seu banco de dados? No caso de bancos de dados locais, é mais difícil explorar, mas em servidores de hospedagem compartilhada, você pode ter 100 sites compartilhando o servidor com você, você pode confiar neles para que estejam protegidos o suficiente para que Mr Evil não possa invadi-los e usá-los para atacar seu site?
fonte