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

Мануал

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

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

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

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

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

127.0.0.1 – – [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)”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

127.0.0.1 – – [31/Jan/2021: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)”
  • 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’

192.168.1.85 – – [31/Jan/2022:22:58:14 +0800] “GET /site/?id=1 union+select+1%2C2%2C3– HTTP/1.1″ 200 379 “http://192.168.1.99/site/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36”

192.168.1.85 – – [31/Jan/2022:22:58:21 +0800] “GET /site/?id=1 union+select+1%2C2%2C3%2C4– HTTP/1.1″ 200 379 “http://192.168.1.99/site/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36”

192.168.1.85 – – [31/Jan/2022:22:58:29 +0800] “GET /site/?id=1 union+select+1%2C2%2C3%2C4%2C5– HTTP/1.1″ 200 379 “http://192.168.1.99/site/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36”

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

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

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

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

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

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

$ tail -n 3 mysql-logs.log 

2022-01-31T15:06:32.689985Z   23 Connect root@localhost on infosec using Socket

2022-01-31T15:06:32.690109Z   23 Query SELECT * FROM products where ID=1 union select 1,2,3,4,5–

2022-01-31T15:06:32.690579Z   23 Quit

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

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

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

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

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

$ cat access.log | grep ‘passwd’

192.168.1.85 – – [31/Jan/2021:22:59:54 +0800] “GET /site/?id=..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd HTTP/1.1″ 200 380 “http://192.168.1.99/site/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36”

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

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

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

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

Заключение

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

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

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

 

Добавить комментарий