У меня есть сервер, на котором уже около месяца работает Fedora 16 (3.1.0-7.fc16.x86_64). Я вхожу в систему только каждые несколько дней или недель, но иногда в моем домашнем каталоге отсутствуют файлы. Я не храню там никаких документов или чего-либо еще, поэтому я не могу сказать, в какой степени у меня есть проблема, но я знаю, что .bash_profile, .bashrc, а иногда и содержимое .ssh / (keyfiles, config , authorized_keys) иногда пропадают. Они просто исчезают (и не всегда сразу, сегодня файлы bash пропали, на прошлой неделе .ssh был пуст). Я не могу найти ничего об этом в Интернете (это не те проблемы, которые у людей были с чистыми установками и начальными обновлениями, поскольку система регулярно обновляется, поэтому проблемы с начальными обновлениями и установкой должны быть устранены, а не повторяться).
# /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
Вчера я добавил оба эти правила в audit.rules
-w /home/me/ -p wa -k homedir_watch
-w /home/me/ -k whodeletedit -p w
и сегодня .bashrc снова исчез, но когда я ищу с любым из этих
ausearch -f /home/lockhart -k homedir_watch
ausearch -i -k whodeletedit
я получил
<no matches>
Однако я получаю то же самое, когда добавляю / воссоздаю отсутствующие файлы - совпадений по-прежнему нет.
Если у вас есть доступ к серверу на уровне root, вы можете установить и включить auditd который отслеживает изменения на уровне файловой системы и поможет вам определить, что отвечает за удаление файла.
Затем вы создали следите за записью в ваш домашний каталог (удаление файла из каталога требует записи в каталог, содержащий его), возможно, пометив его, чтобы вы могли держать его отдельно от других запущенных часов:
auditctl -w /home/you/ -k whodeletedit -p w
Когда файл снова пропадает
ausearch -i -k whodeletedit
расскажет, что изменило ваш домашний каталог.
Все это предполагает нормальную работу системы и то, что файлы не пропадают из-за повреждения диска или неправильного выключения системы и потери данных.
Что касается криминалистической экспертизы прошлых событий, это зависит от того, какие журналы и настройки вы настроили.
На базовом уровне вы должны иметь возможность просмотреть, когда последний раз изменялся проблемный файл, и другую соответствующую информацию, используя stat инструмент такой;
`$ 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: -`
Это укажет, когда файл был изменен.
Вы можете сравнить это значение отметки времени с записями в /var/log/secure file и другие журналы событий, произошедших в то время, когда файл был обнулен, поэтому вы ищете пользователей, вошедших в систему и т. д., или команды sudo.
Для будущих событий вы можете установить и настроить служба демона аудита следить за своим домашним каталогом вот так;
$ 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
настроить сервис auditd для запуска
# service auditd start
Redirecting to /bin/systemctl start auditd.service
и быть включенным при загрузке;
# 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'
и настройте часы в своем домашнем каталоге, добавив следующее в конец /etc/audit/audit.rules файл;
-w /home/user1 -p wa -k homedir_watch
а затем вы можете искать изменения в файлах в журналах следующим образом;
# 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"
будьте осторожны, это может довольно быстро запустить множество журналов, поэтому, если вы собираетесь использовать его и оставить работающим, то есть несколько хороших документы здесь