.bashrc e .ssh / desaparecendo aparentemente aleatoriamente

Question

Eu tenho um servidor que está executando o Fedora 16 (3.1.0-7.fc16.x86_64) há cerca de um mês. Eu faço o login apenas a cada poucos dias ou semanas, mas quando faço isso, às vezes os arquivos estão faltando no meu diretório pessoal. Eu não guardo nenhum documento ou qualquer coisa lá, então não posso dizer até que ponto tenho o problema, mas sei que o .bash_profile, .bashrc e algumas vezes o conteúdo de .ssh / (keyfiles, config , authorized_keys) às vezes desaparecem. Eles simplesmente desaparecem (e nem sempre de uma só vez, hoje os arquivos do bash foram embora, na semana passada o .ssh estava vazio). Não consigo encontrar nada sobre isso on-line (não são os problemas que as pessoas estavam tendo com instalações limpas e atualizações iniciais, na medida em que o sistema é atualizado regularmente para que as atualizações iniciais e os problemas de instalação sejam concluídos, não sejam recorrentes).

# /etc/fstab
# ...
/dev/mapper/vg_host-lv_root /                       ext4    defaults        1 1
UUID=1e51ac20-4a4c-4060-b1d2-11a675d082f2 /boot                   ext4    defaults        1 2
UUID=8D78-47C0          /boot/efi               vfat    umask=0077,shortname=winnt 0 0
/dev/mapper/vg_host-lv_home /home                   ext4    defaults        1 2
/dev/mapper/vg_host-lv_swap swap                    swap    defaults        0 0

Eu adicionei essas duas regras para audit.rules ontem

-w /home/me/ -p wa -k homedir_watch
-w /home/me/ -k whodeletedit -p w

e hoje .bashrc sumiu novamente, mas quando eu pesquiso com um desses

ausearch -f /home/lockhart  -k homedir_watch
ausearch -i -k whodeletedit

Eu obtenho

<no matches>

No entanto, recebo o mesmo quando adiciono / recroio os arquivos ausentes - ainda não há correspondências.

    

Answer 1

Se você tiver acesso em nível de raiz ao servidor, poderá instalar e ativar auditd que rastreia o sistema de arquivos mudanças de nível e irá ajudá-lo a identificar o que é responsável por remover o arquivo.

Você criaria um relógio para as gravações na sua casa diretório (excluir um arquivo de um diretório requer gravação no diretório que o contém) possivelmente marcando-o para que você possa mantê-lo separado de outros relógios em execução:

auditctl -w /home/you/ -k whodeletedit -p w

Quando o arquivo desaparece novamente

ausearch -i -k whodeletedit

dirá o que mudou seu diretório pessoal.

Isso tudo pressupõe a operação normal do sistema e que os arquivos não estão faltando devido à corrupção da unidade ou o sistema sendo desligado incorretamente e perdendo dados.

    

Answer 2

Em termos de perícia forense nos eventos passados, isso depende de quais registros e configurações você configurou.

No nível básico, você deve poder ver quando o arquivo do problema foi modificado pela última vez, e outras informações relevantes usando a ferramenta stat , como assim;

'$ stat ~/.bash_profile
  File: '/home/user1/.bash_profile'
  Size: 497             Blocks: 8          IO Block: 4096   regular file
Device: fd02h/64770d    Inode: 1049582     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user1)   Gid: ( 1000/    tomh)
Access: 2012-05-19 15:36:18.691678693 +0100
Modify: 2012-03-30 03:18:35.522606708 +0100  <---- file was changed this time
Change: 2012-03-30 03:18:35.545606708 +0100
 Birth: -'

Isso indicará quando o arquivo foi alterado.

Você pode comparar esse valor de registro de data e hora com entradas no arquivo /var/log/secure e os outros registros para eventos em torno do tempo em que o arquivo foi zerado, portanto você está procurando usuários registrados nos comandos etc ou sudo.

Para eventos futuros, você pode instalar e configurar as serviço de daemon de auditoria para assistir ao seu diretório inicial da maneira;

$ sudo yum install audit
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
Package audit-2.2.1-1.fc16.x86_64 already installed and latest version

configure o serviço auditd para iniciar

# service auditd start
Redirecting to /bin/systemctl  start auditd.service

e esteja habilitado na inicialização;

# chkconfig auditd on
Note: Forwarding request to 'systemctl enable auditd.service'.
ln -s '/lib/systemd/system/auditd.service' '/etc/systemd/system/multi-user.target.wants/auditd.service'

e configure um relógio no seu diretório pessoal adicionando o seguinte ao final do arquivo /etc/audit/audit.rules ;

 -w /home/user1 -p wa -k homedir_watch

e, em seguida, você pode procurar por alterações nos arquivos nos registros, como assim;

 # ausearch -i -k homedir_watch


----
time->Sat May 19 16:53:00 2012
type=PATH msg=audit(1337442780.935:1274): item=1 name="/home/user1/.config/google-chrome/Default/Cookies-journal" inode=1050743 dev=fd:02 mode=0100644 ouid=1000 ogid=1000 rdev=00:00
type=PATH msg=audit(1337442780.935:1274): item=0 name="/home/user1/.config/google-chrome/Default/" inode=1056816 dev=fd:02 mode=040700 ouid=1000 ogid=1000 rdev=00:00
type=CWD msg=audit(1337442780.935:1274):  cwd="/home/user1"
type=SYSCALL msg=audit(1337442780.935:1274): arch=c000003e syscall=2 success=yes exit=104 a0=7fcece769259 a1=42 a2=1a4 a3=30 items=2 ppid=1 pid=8151 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="Chrome_DBThread" exe="/opt/google/chrome/chrome" key="homedir_watch"

• Notas

Cuidado, isso pode executar muitos logs rapidamente, então se você pretende usá-lo e deixá-lo rodando, então existem alguns bons docs aqui