2

I have a server that has been running Fedora 16 ( 3.1.0-7.fc16.x86_64 ) for about a month now. I only log in every few days or weeks, but when I do, sometimes files are missing from my home directory. I don't keep any documents or whatever in there, so I can't say to what extent I have the problem, but I do know that the .bash_profile, .bashrc, and sometimes the contents of .ssh/ (keyfiles, config, authorized_keys) sometimes go missing. They just disappear (and not always all at once, today the bash files were gone, last week .ssh was empty). I can't seem to find anything about it online (it's not the problems people were having with clean installations and initial updates, insofar as the system gets updated regularly so the initial updates and installation issues should be over, not recurring). 

# /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

I added both of these rules to audit.rules yesterday

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

and today .bashrc is gone again, but when I search with either of these

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

I get

<no matches>

However, I get the same when I add/recreate the missing files- there are still no matches.

kaz
  • 141
  • 3

2 Answers2

3

If you have root-level access to the server you can install and enable auditd which tracks filesystem-level changes and will help you identify what is responsible for removing the file.

You'd then set up a watch for writes to your home directory (deleting a file from a directory requires writing to the directory containing it) possibly tagging it so you can keep it separate from other watches running:

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

When the file goes missing again

ausearch -i -k whodeletedit

will tell you what changed your home directory.

This all assumes normal operation of the system and that the files aren't going missing due to drive corruption or the system being improperly shut down and losing data.

DerfK
  • 19,493
  • 2
  • 38
  • 54
1

In terms of forensics on the past events, it depends on what logging and settings you have configured.

At the basic level you should be able to view when the problem file last changed, and other relevant information using the stat tool like so;

`$ 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: -`

This will indicate when the file was changed.

You can compare this timestamp value with entries in the /var/log/secure file, and the other logs for events around the time the file got zeroed, so you are looking for users logged in etc, or sudo commands.

For future events you can install and configure the audit daemon service to watch your home directory like so;

$ 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 the auditd service to start 

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

and be enabled on boot; 

# 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'

and the configure a watch on your home directory by adding the following to the end of the /etc/audit/audit.rules file;

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

and then you can search for changes to the files in the logs like so;

 # 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"
  • Notes

beware, that can run up a lot of logs quite quickly, so if you intend to use it and leave it running, then there are some good docs here

Tom
  • 11,176
  • 5
  • 41
  • 63
  • There are no matches when I try this. – kaz May 20 '12 at 22:00
  • run this query instead `ausearch -i -k homedir_watch ` – Tom May 21 '12 at 08:02
  • also, can you double-check that the auditd service is running (I updated the answer to demonstrate how.... – Tom May 21 '12 at 08:03
  • My mistake- I started the service before adding the rules, and did not restart it after. It now records logs when events happen, since I restarted it. – kaz May 21 '12 at 19:57
  • any luck? interesting problem, would like to know how it is resolved – Tom May 23 '12 at 07:10
  • I am waiting for the problem to happen again, now that logging is working. I mentioned it to a few users who also have sudo powers... and the problem mysteriously hasn't happened since then, not that anyone would /ever/ abuse sudo... I will keep this updated though. – kaz May 24 '12 at 17:47