Практически ко всем, у кого на сервере есть шара, пользователи приходили с жалобой: «У меня тут файлик был, а теперь он пропал…». И обычно это какой-то очень важный файл, который вот прям сейчас нужно куда-то отправить. Естественно, нужно файл найти (восстановить), или, хотя бы, найти виновных (а иначе виновным назначить могут тебя).
В этой заметке я расскажу, как найти нехорошего человека удалившего очень важный файл.
Первым делом нужно задать правила аудита в /etc/samba/smb.conf. Для этого добавьте следующие строки в секцию [global]:
# Audit settings full_audit:prefix = %u|%I|%S full_audit:failure = connect full_audit:success = rmdir write pwrite sendfile rename unlink chmod fchmod chown fchown ftruncate symlink link mknod full_audit:facility = local5 full_audit:priority = noticeПолный перечень возможных событий;
Допустимые переменные для full_audit:prefix.
Теперь к описанию каждой шары, за которой мы хотим следить, нужно добавить строку
vfs objects = full_auditПосле этого в /var/log/messages будет записываться любая неудачная попытка подключения к шаре, и любое успешное изменение файла. Чтобы не засорять системный журнал, нужно вынести эти сообщения в отдельный файл. Для этого нужно создать файл /etc/rsyslog.d/00-samba-audit.conf с содержимым
local5.notice /var/log/samba/audit.log & ~И добавить исключение в /etc/rsyslog.d/50-default.conf, вписав в строку
*.*;auth,authpriv.none -/var/log/syslogсообщения от самбы. Строка примет примерно такой вид:
*.*;local5,auth,authpriv.none -/var/log/syslog
И, наконец, нужно настроить logrotate, чтобы лог самбы не съел всё свободное место на разделе. Создайте файл /etc/logrotate.d/samba.audit со следующим содержимым:
/var/log/samba/audit.log { weekly missingok rotate 7 postrotate /etc/init.d/syslog-ng reload > /dev/null 2>&1 || true endscript compress notifempty }
Теперь перезапустите самбу, и всё готово:
/etc/init.d/samba restart