Algum processo no meu servidor de produção, um projeto que eu herdei de outro desenvolvedor da web, está criando um backup diário dos bancos de dados e arquivos de site do mysql. Os backups estão sendo armazenados /var/www/html/nightlybackup/e eu gostaria de movê-los /var/www/backups/, bem como remover um diretório que não existe mais e adicionar um novo diretório.

Como posso começar a desvendar onde esse processo é definido para que eu possa fazer algumas alterações?

Estou usando o Debian 8

"Coisas para tentar"

Amostragem aleatória / cutucando

• Chance de encontrar o culpado: 50%
• Dificuldade: Fácil assumindo que você sabe o que você está olhando

Procure nos seguintes locais por comandos incomuns / inesperados:

• ~/bin de quaisquer usuários interativos
• ps -ef (como root) para qualquer coisa que você não sabe o que é
• crontab -epara editar o crontabarquivo (tabela cron) para determinar se ele está sendo executado como um cron job a cada X minutos / horas / dias.
• ~/.profileou ~/.bashrcde qualquer usuário
• /usr/local/bin para todos os arquivos que não fazem parte de um pacote gerenciado
• /opt
• Instâncias de linguagens de script: bash, java, perl, python, ruby, etc. - que você não iniciou, ou cujo PPID(pai PID) psnão leva a árvore a um processo com o qual você está familiarizado e sabe disso não está fazendo isso
• Veja se eles nomearam o script / arquivo executável a mesma coisa que o diretório: find / -iname \*nightly\*(poderia retornar muitos falsos positivos, então talvez acrescentar | lessseria prudente)

Existem várias outras maneiras de fazer isso, por exemplo, em um servidor de aplicativos Java, em um script Perl CGI, etc., mas isso é um começo.

Método de Busca Hack-Quick-n-Dirty Semi-Confiável

• Chance de encontrar o culpado: 95%
• Dificuldade: Fácil (apenas execute este script que eu hackeei juntos em 5 minutos)

nohup lsof -r 2 +D /var/www/html/nightlybackup 2>&1 | gzip > nightlybackup-writers.txt.gz &

Em resumo:

• nohup impede que a linha de comando seja encerrada quando você fecha o terminal ou a sessão SSH.
• lsof"lista arquivos abertos", e o faz recursivamente no diretório ( +D), recorrendo indefinidamente ( -r) e atualizando a cada 2 segundos.
• gzip os resultados no caso de você ter muito, para evitar o rápido preenchimento de seu disco.
• Você pode ver os resultados com o zlesscomando.

Esse comando pode ter um impacto significativo no desempenho, especialmente em (1) kernels antigos ou (2) sistemas baseados em HDD. Então, execute-o por um curto período de tempo e determine quanto CPU / disco está usando, e se for muito, mate o processo.

Você terá que deixá-lo em execução durante o tempo que o processo de backup noturno é executado. Este é geralmente o caso de qualquer mecanismo que possa detectar este programa de forma confiável.

Ultimate Swiss Army Knives

• Chance de encontrar o culpado: 99.999999%
• Dificuldade: Extreme (conhecimento do nível do desenvolvedor do SO necessário, ou ter sorte e copiar um script pré-feito que faz o que você quer)

O DTrace e o SystemTap são as ferramentas finais para monitorar o sistema em um determinado padrão de atividade. DTrace é indiscutivelmente melhor, mas muitas pessoas parecem pensar que é um lance-up ou que SystemTap é melhor porque é "nativo" para Linux (DTrace foi adicionado mais tarde depois de ter sido originalmente concebido para Solaris.)

Você pode criar um comando / script do DTrace ou SystemTap para capturar quem está escrevendo em qualquer caminho nesse diretório. Aqui está um exemplo de falha do servidor, juntamente com um link útil para uma série de one-liners do DTrace . Então, basta executá-lo em segundo plano (por exemplo, via screenou nohup) e esperar até que os backups sejam acionados e você receberá um nome de processo e um PID.

A menos que você tenha um rootkit e esse rootkit tenha sido projetado para mascarar sua atividade do DTrace / SystemTap, e supondo que você tenha o comando DTrace ou SystemTap correto, isso VAI descobrir o que está fazendo isso. Mas também é o método mais difícil.