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

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

• Владимир - собственно я
• Илья - разработчик, который написал приложение
• Олег - администратор
• Емельян - ещё один администратор
• Эльдар - ещё один администратор
• Пользователь – вскоре вы узнаете почему безымянный

Так вот с чего началась вообще вся эта заварушка, некий Пользователь зашёл на наш веб-портал, где воспользовался некой услугой. Во время прохождения всех проверок выполнился запрос к сторонней организации (интеграция с гос бд) для проверки статуса человека. Через какое-то время этот Пользователь об этом узнал и накатал на нас заявление, мол как они могли и так далее. Да, пользовательское соглашение Пользователь конечно же подписал, но какое это имеет значение.

Так вот государственные органы решили нас проверить, т.е. отработать заявление. Как только мы поняли в чем Пользователь нас обвиняет стало понятно, что мы и не запрашивали эту информацию, о которой Пользователь так беспокоился. Илья (разработчик) сказал, что с лёгкостью это докажет, так как полный ответ запроса сохраняется в виде log файла на сервере. Осталось дело за малым, и он пришёл к Эльдару дабы тот нашёл этот файл и показал Илье, ну и проверяющей стороне.

Вот тут всё и начинается. Эльдар, зайдя на сервер обнаруживает что файла то этого нет, нас интересует файл от 24.01.2025. На сервере же нет log файлов (логов) в промежутке с 14.12.2024 до 15.03.2025, с учётом того что есть все файлы с 01.03.2023 по 14.12.2024 и после 15.03.2025, правда какая-то часть на другом сервере.

Дело в том, что файлы эти весят очень много и время от времени мы переносим их на другой сервер. Так вот именно Эльдар не-так давно перенёс все файлы за 2023 и что-то за 2024 на другой сервер. Он обращается за помощью к Емельяну, который считает, что может быть просто этот файл в последнем архиве за 14.12.2024 или в архиве за 15.03.2025. И они его не находят ни там, ни там.

Теория №1️⃣

Тут уже подключаюсь я (Владимир). Эльдар предполагает, что кто-то при переносе этих файлов на другой сервер мог их удалить и каким-то образом их не скопировать. Дело в том, что не только он один этим занимается. Дабы проверить эту теорию я захожу на SIEM систему и штудирую логи на предмет удаления файлов (все команды на сервере записываются). Как и ожидалось никто ничего не удалял, в этом я и не сомневался.

Теория №2️⃣

Появилась идея проверить каким образом эти файлы создаются и архивируются, дело в том, что каждый день создаётся архив с файлами. Мало ли как-то криво сработал cron или ещё что-то. Для этого мне нужно проверить логи системы в период с 14.12.2024 по 15.03.2025. Я захожу на сервер и пытаюсь прочитать содержимое /var/log/messages и тут я в ужасе понимаю, что последняя запись от 21.09.2024. Я тогда конечно подумал, что это конец, у меня нет ничего чтобы понять, что произошло. Собрался с мыслями и решил понять почему нет логов в /var/log/messages. В итоге по тем же логам SIEM я увидел, что 21.09.2024 Емельян удалял пакет logrotate, точнее переустанавливал его. Не буду расписывать чем именно это закончилось, просто скажу, что причину я нашел и починил. Если интересно можно прочитать тут.

Теория №3️⃣

Пока я разбирался с /var/log/messages я понял, что архивированием log файлов занимается само приложение. Появилась мысль что может кто-то из разработчиков случайно выложил что-то коряво и отключил логирование запросов интеграций. Илья пошёл проверять и вернулся с новостью что никто ничего не менял.

Тут я уже готов был сдаться, ведь самих файлов на сервере нет, логов всей системы на сервере нет с 21.09.2024 года. Чем мне собственно оперировать?

Теория №4️⃣

Точнее сказать это и не теория в общем а просто я решил проверить делали ли что-то с этим сервером на виртуализации (это виртуальный сервер). Я захожу на SIEM и вижу, что Олег выключает виртуальную машину (сервер где приложение) 14.12.2024 после создаёт вторую. Для лучшего понимания назовём SRV1 (сервер, который есть у меня сейчас) и SRV1_NEW (сервер, который создал и включил Олег с тем же ip). Соответственно к Олегу возникает вопрос: Зачем ты это сделал? На что Олег отвечает: это был 2024 год, я уже не помню. И вот тут уже сама Теория №4: файлы с 14.12.2024 по 15.03.2025 на сервере SRV1_NEW, осталось только его включить и получить доступ к файлам.

Но вот вопрос ведь сейчас запущен SRV1, почему? Захожу я на систему виртуализации и ищу SRV1_NEW и что вы думаете? Я его не нахожу (

Теория №5️⃣

Сервер SRV1_NEW кто-то дропнул и не видать теперь нам этих файлов. Но надо же удостоверится что его удалили. Снова иду в SIEM проверять логи и вижу только, что SRV1 был включен 15.03.2025 и никаких записей больше про SRV1_NEW, кроме последней где его включили 14.12.2024 (было пару reconfigre позже). Начинаем думать почему включили SRV1 15.03.2025 года и находим запись о том, что в этот день помер сервер виртуализации (померла планка ОЗУ).

Теория №6️⃣

Теперь, когда мы знаем, что помер сервер виртуализации и нет записи о том, что SRV1_NEW кто-то удалил логично предположить, что мы в тот день 15.03.2025 вручную регистрировали виртуальные машины с СХД на другом сервере виртуализации и так как про SRV1_NEW знали не все просто зарегистрировали только SRV1, ведь по сути это полностью рабочий сервер, зачем создали второй так и осталось тайной. Я полез на СХД искать SRV1_NEW и спустя какое-то время нашёл его. После чего я его зарегистрировал в виртуализации и включил, где и нашёл файлы с 14.12.2024 по 15.03.2025. В итоге наши жопы спасены и можно успокоить Пользователя что данные его наша система не получила, по крайней мере о которых он так переживал.

Выводы:

• Старайтесь использовать SIEM, т.е. логируйте всё что можно. Логи очень пригодятся для доказательства вашей же невиновности
• Конечно же нужно делать резервные копии и хранить как можно больше точек восстановления (но наш сервер весит около 5 ТБ).
• Когда удаляешь какой-то пакет проверь что он унесёт вместе с собой