Estou administrando um servidor debian desde a semana passada. Costumava ter outro administrador.
Presumo que tenha sido hackeado: os arquivos podem ter sido lidos via SFTP para obter informações sobre um site hospedado no servidor que estou mencionando e, em seguida, as tabelas foram excluídas do banco de dados via PhpMyAdmin.
Estou prestes a desistir aqui, já que o phpmyadmin não registra a atividade por padrão e o SFTP também não. A atividade SFTP do servidor e o phpmyadmin não foram configurados para enviar dados para arquivos de log.
O plausível "hacker" cometeu o erro de acessar o servidor com um usuário que eu não sabia que existia, algumas vezes via SSH! no entanto, não consegui rastrear mais nenhuma atividade, pois ele teve o cuidado de navegar apenas para a pasta onde o site está hospedado (diretamente, sem nem mexer nos arquivos, para que ele conhecesse claramente o servidor) o resto do atividade foi feita através do phpmyadmin e SFTP.
Poucas pessoas sabiam sobre esse usuário no servidor, como você provavelmente está percebendo, já que NÃO era root, e eu tenho o endereço IP dele que todos sabemos que não ajudará muito.
Tudo que ele fazia no servidor, quando logado como o outro usuário, era cdpara o diretório onde o site mora, fazia um diretório lá chamado "m" e pronto; o diretório "m" foi removido, não foi removido usando o terminal por mim, nem pelo intruso.
O arquivo /etc/ssh/sshd_configagora está configurado para rastrear a atividade e funciona, mas é claro que é um pouco tarde demais, infelizmente.
Você pode me ajudar a encontrar uma maneira de rastrear a atividade SFTP ou qualquer outra maneira de rastrear a atividade de um usuário de um servidor específico que não seja executar o historycomando fazendo login como esse usuário via SSH? OBRIGADO!
Não foi possível rastrear a atividade do SFTP.
Infelizmente, não consegui encontrar informações sobre a atividade do SFTP, antes das alterações feitas após os ataques. No entanto, os logs do apache foram muito úteis aqui, e como os provedores de internet locais não alteram os IPs públicos com tanta frequência, conseguimos determinar que as tabelas ausentes que mencionei foram feitas pelo mesmo endereço IP, e também conhecemos o dispositivo que foi usado para realizar as consultas.
Mas nem precisamos construir uma máquina do tempo, afinal...
Qualquer pessoa lidando com uma situação semelhante pode verificar os logs do apache e descobrir informações cruciais sobre como/quando a atividade maliciosa ocorreu e ter uma ideia de quem a fez.