Анализ логов имеет большое значение в расследовании, и эта статья представляет собой небольшое введение в аудит журналов.
Файл лога может содержать такую информацию, как кто получает доступ к активам компании, как он/она получает доступ, когда и сколько раз.
Анализ логов может быть различным для разных типов атак и источников журналов.
В данной статье рассматривается аудит логов, взятых с веб-сервера.
Ниже приведен пример лога доступа к веб-серверу:
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 в данном случае не обязательно означает, что файл был успешно прочитан.
Это требует дальнейшего расследования.
Заключение
В этой статье были приведены примеры анализа журналов на примере простой веб-атаки, но анализ журналов может быть гораздо более сложным при расследовании реальных атак.
Это связано с тем, что расследователи часто получают огромные объемы логов, и корреляция становится вынужденной необходимостью для облегчения процесса анализа.
Кроме того, злоумышленники используют скрытные методы, и в зависимости от сложности расследуемой атаки анализ в большинстве случаев может быть довольно сложным.
