Как узнать, кто удалил файл на Linux-сервере

Удаление нужного файла почти всегда превращается в неприятный сюрприз. Особенно на рабочем Linux-сервере или VPS, где одновременно запускаются скрипты, работают контейнеры, выполняются CI/CD-пайплайны, а доступ к системе есть у нескольких пользователей. В такие моменты обычно пытаются выяснить не только как вернуть файл, но и то, кто именно его удалил.

У этого вопроса нет универсального ответа, ведь Linux по умолчанию не ведёт отдельный журнал удалений, поэтому после инцидента всё зависит от того, какие средства аудита и мониторинга были включены заранее. А вот если их не было, то расследование быстро превращается в поиск косвенных следов.

В этой краткой статье давайте попробуем разобраться, где есть смысл искать информацию и какие инструменты действительно помогают понять, что именно произошло.

Почему Linux не хранит историю удаления файлов

Многие ожидают увидеть некий аналог Журнала событий Windows с записью о том, какой пользователь удалил конкретный файл и в какое время это произошло. Но к сожалению, в большинстве Linux-дистрибутивов такого механизма не существует.

Фактически, при использовании команды rm удаляется ссылка на inode файловой системы. И если заранее не был включён аудит файловых операций, то после удаления остаются лишь косвенные следы.

Кроме того, файл мог удалить не человек, а например cron-задача, systemd timer, процесс резервного копирования, Docker контейнер или само приложение, очищающее временные данные. Поэтому расследование подобных инцидентов обычно строится на анализе сразу нескольких источников информации.

Проверьте историю команд Bash

Если файл удалили вручную через терминал, то первое с чего стоит начать - это с истории команд Bash. Иногда этого уже становится достаточно, чтобы найти виновника.

Сделать это можно, например, выполнив в консоли сервера команду:

history

или

cat ~/.bash_history

Если доступ к серверу есть у нескольких пользователей, то нужно проверить историю каждого аккаунта. Также не забывайте и про root, так как часто пользователь сначала входит под своей учётной записью, затем выполняет sudo, и команда rm остаётся уже в истории суперпользователя.

Но всё же полностью полагаться на Bash History не стоит. Запись истории обычно происходит только после завершения сеанса. Опять же, пользователь может отключить её сохранение, удалить файл .bash_history или просто очистить историю перед выходом из системы. Поэтому этот способ полезен скорее как первая проверка, чем как надёжное доказательство.

Изучите системные журналы

Даже если сам факт удаления файла нигде не записан, то системные журналы часто помогают восстановить последовательность событий, сопоставив данные из нескольких основных логов.

В первую очередь стоит проверить логи авторизации и системные журналы событий:

• /var/log/auth.log;
• /var/log/secure;
• журнал systemd через journalctl;
• логи служб, которые могли работать с этим файлом.

По журналам обычно удаётся выяснить, кто входил на сервер незадолго до инцидента, были ли SSH-подключения, использовался ли sudo, запускались ли задания cron или другие автоматические процессы. Очень часто раскладки событий на одной временной шкале уже хватает, чтобы отбросить большую часть версий.

Но, увы, и в данном случае есть нюанс. Заключается он в том, что если аудит файловой системы не был настроен заранее, то журналы помогут понять общий ход событий, но вряд ли покажут, какой именно пользователь удалил конкретный файл.

Приложения и контейнеры

Все мы знаем, что удалить файл может не только человек, но и какие либо приложения или средства автоматизации. Среди самых распространённых источников таких изменений часто фигурируют:

• Docker-контейнеры;
• задания Kubernetes (Job, CronJob);
• GitHub Actions, GitLab Runner и другие CI/CD-инструменты;
• системы резервного копирования и синхронизации;
• CMS, собственные приложения и служебные скрипты.

Типичным примером может являться такой случай, когда контейнер, запущенный от имени root, получает доступ к смонтированному тому и удаляет файлы внутри него. В такой ситуации история Bash команд почти ничего не даст. Куда полезнее в подобном случае будет изучить журналы Docker, Kubernetes или самого приложения.

Это ещё раз доказывает, что расследование инцидентов лучше не сводить к поиску действий конкретного пользователя, ведь причиной может быть что угодно.

Можно ли восстановить картину после удаления

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

Обычно в таких случаях проверяют и сопоставляют такие данные как:

• время изменения родительского каталога;
• журналы приложений и сервисов;
• историю выполнения cron;
• системные журналы;
• резервные копии;
• данные систем мониторинга.

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

Когда ни аудит, ни журналы, ни другие средства контроля не использовались, установить виновника уже, как правило, не получится.

Как подготовить сервер заранее

Если в вашей работе вам часто нужно знать, кто удалил файл, изменил права доступа или переименовал какой либо каталог, то вам лучше заранее настроить Linux Audit Framework (auditd). Для таких задач это один из самых эффективных встроенных инструментов.

auditd умеет фиксировать такие события как:

• удаление файлов;
• создание и изменение файлов;
• изменение прав доступа и владельца;
• переименование объектов;
• обращения к указанным файлам и каталогам.

Например, вы можете включить аудит конкретного каталога:

auditctl -w /var/www -p wa

После этого auditd начнёт записывать все подходящие события. В журнал попадут время выполнения операции, пользователь, процесс, PID и другие данные, которые помогают восстановить картину произошедшего.

Правила удобнее создавать с собственными ключами, тогда искать нужные записи станет гораздо проще:

auditctl -w /var/www -p wa -k webfiles

После этого события можно отфильтровать по ключу:

ausearch -k webfiles

А если нужен общий отчёт по накопленным данным, тогда пригодится утилита aureport.

Именно auditd обычно используют на корпоративных серверах, где есть требования к аудиту действий пользователей, расследованию инцидентов и контролю изменений в системе.

Вывод

К большому сожалению, достоверно узнать, кто удалил тот или иной файл на Linux-сервере, удаётся только в том случае, если система заранее собирала нужные данные. Без аудита приходится сопоставлять историю команд, системные журналы, логи приложений и сведения о работе автоматических процессов. Иногда этого хватает, но зачастую информации слишком мало, чтобы делать выводы.

По этой причине механизмы контроля лучше настраивать ещё до появления проблемы. Утилита auditd, централизованный сбор журналов, регулярные резервные копии и мониторинг системы заметно упрощают расследование любых инцидентов, а заодно помогают и быстрее восстановить работу сервера и понять, почему ситуация вообще возникла.