Журналирование. Почему нужны журналы и зачем их защищать?

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

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

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

Помимо получаемых веб-сервером запросов журналировать можно события в операционной системе, на серверах баз данных, в различных средствах безопасности, в пользовательских приложениях, на внешнем прокси-сервере и другие. Если нас интересует только веб-сервер и то, что происходит с ним, то и события нас будут интересовать только его. Если же нас интересует общее состояние защищенности и работоспособности информационной системы, то есть смысл следить за событиями на разных ее узлах, а также на сетевом оборудовании. Это позволит отслеживать более сложные взаимодействия внутри системы. Например, в системе появился вирус — по журналам можно попробовать определить, как и куда он дальше распространяется и откуда вообще появился. Или если происходит DoS-атака — можно понять, с какого устройства. И так далее.

Очевидно, может происходить много событий разного рода, особенно если речь идет о большой информационной системе. Вручную просматривать все события может быть тяжело, а отделить «обычные» события от «необычных» не так и просто. Например, если пользователь обратился к главной странице некоего веб-сайта — это нормально. Если же за одну секунду пользователь обратился к главной странице того же сайта 100 раз — это уже подозрительно. Но если все 100 обращений совершены с разных IP-адресов, и сделаны они к главной странице какого-то популярного сайта, то данная ситуация снова в порядке вещей. Фильтрацией таких событий, а также мониторингом и поиском корреляций между событиями из разных источников занимаются, например, решения класса SIEM и SOC.

Итак, события журналируются, инциденты детектируются и/или расследуются. А теперь предположим, что у нас есть веб-сервер и некий злоумышленник залил на него веб-шелл. При помощи шелла он внес свои коррективы (удалил какие-то файлы, изменил конфигурацию и т. п.), удалил из журнала запись о POST-запросе с отправкой веб-шелла и о всех своих действиях, после чего удалил шелл и скрылся. Когда последствия его действий будут замечены, соответствующих записей в журнале мы не найдем. Если мы и обнаружим подозрительное изменение временной метки у системных файлов, то этой информации может быть не достаточно для восстановления хода событий и поиска уязвимого места в системе. Именно поэтому журналы необходимо защищать. Ведь при малейшем сомнении в целостности и подлинности записей журнала такому же сомнению подвергается вся получаемая из него информация. Соответственно, ставится под вопрос использование журнала в качестве достоверного источника. Так же и заинтересованный свидетель в суде лишь запутывает следствие.

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

Рекомендации