Como solucionar o processo que está escrevendo um arquivo

Question

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 do site mysql. Os backups estão sendo armazenados em /var/www/html/nightlybackup/ e gostaria de movê-los para /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

    

Answer 1

"Coisas para experimentar"

Amostragem aleatória / cutucando

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

Procure nos seguintes locais comandos incomuns / inesperados:

• ~/bin de quaisquer usuários interativos
• ps -ef (como root) para qualquer coisa que você não saiba o que é
• crontab -e para editar o arquivo crontab (tabela cron) para determinar se ele está sendo executado como uma tarefa cron a cada X minutos / horas / dias.
• ~/.profile ou ~/.bashrc de quaisquer usuários
• /usr/local/bin para qualquer arquivo que não faça 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) em ps não leva a árvore a um processo que você está familiarizado e sei que não está fazendo isso
• Veja se eles nomearam o script / arquivo executável da mesma maneira que o diretório: find / -iname \*nightly\* (poderia retornar muitos falsos positivos, então talvez adicionar | less seria prudente)

Existem milhares de outras maneiras pelas quais eles poderiam ter feito isso, por exemplo. a partir de um servidor de aplicativos Java, um script Perl CGI, etc., mas estes são um começo.

Método de pesquisa semi-confiável rápido-n-sujo Hackish

• 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 &

Resumindo:

• 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 ), recorrente indefinidamente ( -r ) e atualiza a cada 2 segundos.
• gzip os resultados no caso de você ter muito, para evitar o rápido preenchimento do seu disco.
• Você pode visualizar os resultados com o comando zless .

Este 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 demais, mate o processo.

Você terá que deixá-lo rodando durante o tempo que o processo de backup noturno é executado. Este é geralmente o caso de qualquer mecanismo que possa detectar este programa com segurança.

Ultimate Swiss Army Knives

• Possibilidade de encontrar o culpado: 99.999999%
• Dificuldade: Extremo (o nível de conhecimento do desenvolvedor do sistema operacional é necessário ou ter sorte e copiar um script pré-criado que faça o que você deseja)

Ambos DTrace e O SystemTap é a ferramenta ultimate para monitorar o sistema em busca de um padrão específico de atividade. O DTrace é possivelmente melhor, mas muitas pessoas parecem pensar que é um lançamento ou que o SystemTap é melhor porque é "nativo" para o Linux (o DTrace foi adicionado posteriormente depois de ser originalmente projetado para o Solaris).

Você pode criar um comando / script do DTrace ou SystemTap para capturar quem está escrevendo em qualquer caminho nesse diretório. Aqui é um exemplo de falha do servidor, juntamente com um link útil para uma enorme quantidade de DTrace one-liners . Em seguida, basta executá-lo em segundo plano (por exemplo, por meio de screen ou nohup ) e esperar até que os backups sejam atingidos, e você obterá um nome de processo e um PID.

A menos que você tenha um rootkit e esse rootkit tenha sido criado para mascarar sua atividade do DTrace / SystemTap, e supondo que você tenha o comando DTrace ou SystemTap correto, essa WILL encontrará o que está sendo feito. Mas também é o método mais difícil.