Qualquer maneira de determinar como os arquivos foram apagados no servidor Linux / Apache?

Question

PROBLEMA:

Eu tenho vários diretórios ausentes em um servidor Linux / Apache fora do local. Eu rastreei sobre quando eles desapareceram dos logs de erro do httpd, e eu tenho uma lista de logins SSL para a máquina (completa com endereços de rede).

Existem vários indivíduos que têm acesso à minha conta na máquina, por isso estou tentando confirmar se os arquivos foram removidos acidentalmente ou intencionalmente. Se eu puder determinar que a sessão veio de um endereço de rede externo, posso ter certeza de que foi intencional. Caso contrário, precisarei de informações adicionais.

PERGUNTA:

Existe alguma maneira de determinar qual conta de usuário (minha x raiz), sessão de rede ou processo removeu os arquivos? Não estou preocupado em restaurá-los porque os backups são recentes.

PERGUNTA RELACIONADA:

Eu tentei olhar para o histórico do bash para minha própria conta (a única diferente de root com permissão) e ela parece estender-se apenas para o início da minha sessão SSL. Isso implica que o histórico bash foi adulterado ou isso é um comportamento normal?

    

Answer 1

Por padrão, isso não está registrado (imagine o tamanho dos logs). Você pode adicionar logging com auditctl ou inotify / iwatch (opções interessantes, verificá-las), ou o log do painel de controle ou logs de ftp (geralmente todos em / var / log em algum lugar) ou bash podem ajudá-lo a rastreá-lo um pouco. Verifique seus logs de acesso HTTP no caso de alguma requisição GET conseguir fazer isso (improvável, mas possível)

Se o seu histórico não estiver lá, foi limpo. Isso é feito manualmente ou um comando em seus arquivos .bash_logout ou .logout.

Além disso, não é o SSH SSL:)

    

Answer 2

A limpeza é sempre difícil. Recursos que você pode usar:

Para determinar quem efetuou login e de onde:

• last / lastlog
• / var / log / secure (mostra logins bem-sucedidos e com falha na maioria das vezes)

Para determinar o que estava acontecendo no momento:

• ausearch (supondo que você esteja fazendo uma auditoria; se você não estiver, considere começar)
• sar (para descobrir se o sistema estava inativo ou ocupado no momento)

Se não houve muita rotatividade desde o incidente, o mtime no diretório pode ter informações úteis (provavelmente não, mas geralmente gosto de coletar esse tipo de dados de qualquer maneira)

Para o futuro, faça com que cada pessoa com acesso à máquina tenha uma conta própria. O que você tem agora é muito bobo pela razão que você acabou de descobrir; Você não pode saber quem fez o quê.

    

Answer 3

Se você estiver executando a contabilidade do processo, poderá localizar a (s) chamada (s) para o rm no log de contabilidade do processo.

O histórico da Shell pode ter sido removido ou pode ser configurado para o histórico particular da sessão. Sessões concorrentes também podem causar problemas com o histórico do shell.

    

Answer 4

O histórico bash só é gravado quando você fecha o shell (você pode desativá-lo para a sessão atual). Em uma sessão bash em execução, você não pode ver os comandos que você digitou naquela sessão no arquivo bash do histórico - feche a sessão, inicie uma nova e você poderá vê-la.

    

Answer 5

A única forma confiável de fazer isso é executar a contabilidade do sistema (como sar ou similar). Outras coisas podem dar a você a resposta, mas não são garantidas:

1. O histórico do bash não é garantido porque (a) existe um limite de histórico; (b) por padrão, não é escrito instantaneamente; (c) você tem que pesquisar em todo o histórico bash de todas as contas de usuário; (d) as opções de histórico afetam o comportamento; (e) Um usuário pode limpar seu próprio histórico bash (evitar que seja gravado em arquivo).

2. sftp por padrão não registra transações, mas isso pode ser ativado no servidor sftp se necessário. arquivos adicionados ou removidos via sftp ou ftp não são registrados em um arquivo de histórico do shell ou em qualquer outro lugar.

No seu caso particular, se você ainda não está executando a contabilidade, então seu único recurso é pesquisar os históricos de comandos do shell para todas as contas de usuários, na esperança de que sejam preservadas.