Як дізнатися, хто видалив файл на сервері під управлінням 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 не варто. Запис історії зазвичай відбувається лише після завершення сеансу. Знову ж таки, користувач може вимкнути її збереження, видалити файл .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, централізований збір журналів, регулярні резервні копії та моніторинг системи помітно спрощують розслідування будь-яких інцидентів, а заодно допомагають і швидше відновити роботу сервера та зрозуміти, чому ситуація взагалі виникла.