Аудит логов при форензике

Анализ логов имеет большое значение в расследовании, и эта статья представляет собой небольшое введение в аудит журналов.

Файл лога может содержать такую информацию, как кто получает доступ к активам компании, как он/она получает доступ, когда и сколько раз.

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

В данной статье рассматривается аудит логов, взятых с веб-сервера.

• 🌐 Как парсить логи доступа nginx
• 🌐 Как анализировать и интерпретировать логи вебсервера Apache

Ниже приведен пример лога доступа к веб-серверу:

Необходимость анализа логов

Логирование – это просто процесс хранения журналов на сервере.

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

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

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

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

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

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

Превентивные меры, такие как внедрение брандмауэра веб-приложений (WAF), не всегда возможны.

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

Однако следует отметить, что файлы логов имеют свои ограничения.

Логи веб-сервера по умолчанию содержат лишь ограниченную информацию о HTTP-запросах и ответах.

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

Понимание логов доступа

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

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

• 127.0.0.1: IP-адрес клиента.
• [31/Jan/2022:16:09:05 -0400] : Время, когда сервер закончил обработку запроса.
• GET /admin/ HTTP/1.1: Запрошенный клиентом ресурс.
• 200: Код состояния, который сервер отправляет обратно клиенту.
• Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322) : Заголовок HTTP-запроса User-Agent.

Анализ атаки на веб-приложение

Предположим, в оповещении говорится о попытке атаки SQL-инъекции на веб-приложение.

Первое, что необходимо посмотреть, это логи доступа к веб-серверу.

Исследуемый сервер основан на Debian, а местоположение журналов сервера apache по умолчанию в системах Debian – /var/log/apache2/access.log.

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

Следующая выдержка показывает, что мы пытаемся найти все запросы, которые содержат ключевое слово “union” в URL.

cat access.log | grep ‘union’

Как видно из предыдущего отрывка, в логах обнаружены записи со словом union, и очевидно, что кто-то с IP-адресом 192.168.1.85 предпринял попытку SQL-инъекции.

Чтобы проверить, выполняется ли этот запрос базой данных, необходимо изучить логи базы данных.

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

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

В текущем сценарии эти логи хранятся в файле, они получены и сохранены в автономном режиме для исследования.

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

Этот лог не только подтверждает выполнение несанкционированного запроса к базе данных, но также подтверждает, что веб-приложение уязвимо к SQL-инъекциям.

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

Следующая выдержка показывает, что мы ищем запросы, которые пытаются прочитать файл /etc/passwd.

Наличие таких записей является признаком попытки атаки включения локального файла.

Пример может выглядеть следующим образом.

Запись ..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd в журнале представляет собой URL-кодированную версию ../../../../../../etc/passwd, которая является обычной полезной нагрузкой, используемой для проверки уязвимости приложения к локальному чтению файлов.

Ее наличие в логах доступа, безусловно, свидетельствует о попытке атаки.

HTTP-ответ 200 в данном случае не обязательно означает, что файл был успешно прочитан.

Это требует дальнейшего расследования.

Заключение

В этой статье были приведены примеры анализа журналов на примере простой веб-атаки, но анализ журналов может быть гораздо более сложным при расследовании реальных атак.

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

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

Наши проекты:

- Кибер новости: the Matrix
- Хакинг: /me Hacker
- Кодинг: Minor Code