Определение какой команды / скрипта удаляет ваши файлы с помощью inotifywait

Question

Один из наших серверов приложений периодически удаляет файл внутри:

/home/test/data

Проблема в том, что мы до сих пор не знаем, какой скрипт или команда удаляют файлы, поэтому мы пытаемся использовать inotifywait. Мы можем регистрировать дату и время, но не можем получить необходимую информацию. Могу ли я настроить / настроить этот inotify, чтобы показать, кто виновник, который удаляет мои файлы?

Пример журнала:

/opt/asd CREATE 2017/04/03-17:49:05
/opt/asd DELETE 2017/04/03-17:49:11
/opt/wira/.bash_history MODIFY 2017/04/03-17:51:29
/opt/wira/.bash_history MODIFY 2017/04/03-17:51:29
/opt/wira/.bash_history MODIFY 2017/04/03-17:51:29
/home/test/data/test DELETE 2017/04/03-17:52:16
/home/test/data/c/test DELETE 2017/04/03-17:58:00
/home/test/data/c DELETE,ISDIR 2017/04/03-17:58:00

Это наша конфигурация

# specify log file
LOGFILE=/var/log/inotify.log
# specify target directory for monitoring
MONITOR=/home/test/data
# specify target events for monitoring ( comma separated )
# refer ro "man inotifywait" for kinds of events
EVENT=delete,modify,move

Answer 1

Инструмент для этого - Auditd, который

пользовательский компонент системы аудита Linux. Он отвечает за запись записей аудита на диск. Просмотр журналов осуществляется с помощью утилит ausearch или aureport. Настройка правил аудита выполняется с помощью утилиты Auditctl. Во время запуска правила в /etc/audit/audit.rules читаются Auditctl. Сам демон аудита имеет некоторые параметры конфигурации, которые администратор может пожелать настроить. Они находятся в файле audd.conf.

(из Руководства). Чтобы обнаружить удаляемый файл, после установки пакета audd и его запуска вы проверяете папку, содержащую данный файл, следующим образом:

    
    $ touch zz
    $ sudo auditctl -w /home/me -p wa
    $ rm /home/me/zz
    $ sudo cat /var/log/audit/audit.log
    type=DAEMON_START msg=audit(1491310210.803:235): auditd start, ver=2.4.5 format=raw kernel=4.8.0-45-generic auid=4294967295 pid=29913 subj=unconfined  res=success
    type=USER_AUTH msg=audit(1491310280.366:26): pid=30060 uid=1000 auid=1000 ses=2 msg='op=PAM:authentication acct="e" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/6 res=success'
    type=USER_ACCT msg=audit(1491310280.366:27): pid=30060 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting acct="me" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/6 res=success'
    type=USER_CMD msg=audit(1491310280.366:28): pid=30060 uid=1000 auid=1000 ses=2 msg='cwd="/home/me" cmd=617564697463746C202D77202F686F6D652F6D6172696F202D70207761 terminal=pts/6 res=success'
    type=CRED_REFR msg=audit(1491310280.366:29): pid=30060 uid=0 auid=1000 ses=2 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/6 res=success'
    type=USER_START msg=audit(1491310280.366:30): pid=30060 uid=0 auid=1000 ses=2 msg='op=PAM:session_open acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/6 res=success'
    type=CONFIG_CHANGE msg=audit(1491310280.390:31): auid=1000 ses=2 op="add_rule" key=(null) list=4 res=1
    type=USER_END msg=audit(1491310280.390:32): pid=30060 uid=0 auid=1000 ses=2 msg='op=PAM:session_close acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/6 res=success'
    type=CRED_DISP msg=audit(1491310280.390:33): pid=30060 uid=0 auid=1000 ses=2 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/6 res=success'
    type=SYSCALL msg=audit(1491310299.535:34): arch=c000003e syscall=263 success=yes exit=0 a0=ffffff9c a1=21b0000 a2=0 a3=15e items=2 ppid=2441 pid=30087 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts6 ses=2 comm="rm" exe="/bin/rm" key=(null)
    type=CWD msg=audit(1491310299.535:34): cwd="/home/me"
    type=PATH msg=audit(1491310299.535:34): item=0 name="/home/me" inode=23199747 dev=fd:00 mode=040755 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT
    type=PATH msg=audit(1491310299.535:34): item=1 name="zz" inode=23205547 dev=fd:00 mode=0100664 ouid=1000 ogid=1000 rdev=00:00 nametype=DELETE
    type=PROCTITLE msg=audit(1491310299.535:34): proctitle=726D007A7A
    type=USER_CMD msg=audit(1491310321.131:35): pid=30120 uid=1000 auid=1000 ses=2 msg='cwd="/home/me" cmd=636174202F7661722F6C6F672F61756469742F61756469742E6C6F67 terminal=pts/6 res=success'
    type=CRED_REFR msg=audit(1491310321.131:36): pid=30120 uid=0 auid=1000 ses=2 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/6 res=success'
    type=USER_START msg=audit(1491310321.131:37): pid=30120 uid=0 auid=1000 ses=2 msg='op=PAM:session_open acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/6 res=success'

Я использовал жирный шрифт для соответствующего события удаления, где вы можете легко увидеть PPID, PID и пользователя, который выполнил удаление.

Answer 2

Использование inotifywait в качестве ловушки событий - хорошее начало. Однако, как вы заметили, это не говорит вам, кто / что, только когда. Зная, когда это отличный способ сузить преступников. Но вам нужно больше информации.

В качестве быстрого и (очень) грязного решения временно измените права доступа к файлам для вашего каталога данных, чтобы только конкретный пользователь или группа могли изменять / удалять файлы. Это приведет к сбросу сообщений об ошибках, так как приложения (и, возможно, люди) пытаются дотронуться до файлов и получить пощечину. (Предостережение: все, что работает от имени root, обойдёт это, поэтому здесь мой совет запускать приложения / задания из учетных записей служб, а не root).

Эти сообщения об ошибках идентифицируют процесс (ы), пытающийся удалить файлы, и оттуда вы можете дополнительно выяснить, какой скрипт запускает какой процесс, поскольку все дочерние процессы содержат свой родительский процесс, вплоть до init/0. Сценарии, вероятно, будут экземпляром bash, но их родителем будет либо crond (временная работа), либо приложение.

Другой возможный способ - просмотреть таблицы cron, чтобы увидеть, какие задания cron выполняются непосредственно перед тем, как файлы обнуляются. (Если ваши приложения запускают задания, не передавая их в crond, найдите расписание и журналы заданий в приложениях.)