Поиск аномалий в журналах Web-сервера
Log Parser — бесплатная утилита командной строки, в которой запросы SQL и функции интеллектуального анализа баз данных используются для поиска информации в файлах журналов Windows Server 2003, Exchange Server, SQL Server и ISA Server 2004. Администраторы Microsoft Internet Information Services (IIS) 6.0 на платформе Windows 2003 с помощью Log Parser могут обнаружить в журналах события, которые указывают на попытки взломщика проникнуть на Web-сервер. Log Parser не дает прямых сообщений об успешной атаке взломщика против сервера, но, правильно задавая вопросы, можно получить весомые доказательства. В данной статье показано, как с помощью Log Parser собрать статистические данные об IIS 6.0, проверить коды ошибок, обнаружить необычные команды в HTTP-запросах и следить за активностью Web-узла.
Прежде чем читать эту статью, имеет смысл познакомиться с прошлыми публикациями Windows IT Security, которые помогут понять базовые принципы функционирования Log Parser. Знакомство с любой из этих статей не обязательно для понимания изложенного ниже материала, но знание основ поможет лучше понять Log Parser. В частности, рекомендуется прочитать статью «Анализ журналов с помощью LogParser», опубликованную в № 7 Windows IT Pro/RE» за 2004 г. (http://www.osp.ru/text/302/177249/), а также статьи «Посчитаем неудачные попытки регистрации» (http://old.osp.ru/win2000/safety/501_1.htm) и «Фильтрация данных журналов безопасности» (http://old.osp.ru/win2000/safety/501_99.htm). Главный же источник информации о Log Parser — книга Габриэля Джезеппини и Марка Барнетта Microsoft Log Parser Toolkit (издательство Syngress, 2005).
Сбор данных
Прежде чем приступить к анализу файлов журналов IIS, следует убедиться, что собраны все необходимые данные. Для сбора нужных данных требуется настроить политику аудита на Web-сервере, разрешив протоколирование событий IIS. По крайней мере, необходимо составить политику аудита для отслеживания успешных или неудачных исходов следующих событий: регистрация, доступ к объектам и использование полномочий. Аудит событий регистрации позволяет увидеть, как использовались учетные записи для сетевого доступа к информации через Web-сервер. Активизация аудита доступа к объектам в соответствующих папках Web-узла позволяет составить историю доступа к объектам. Аудит доступа к объектам должен быть взвешенным: чрезмерная активность может привести к снижению производительности из-за перегрузки сервера. Аудит использования полномочий позволяет отслеживать действия взломщиков, которые повышают свои полномочия, чтобы расширить возможности доступа. В данной статье не рассматривается собственно вопрос повышения полномочий, но содержатся указания по использованию Log Parser для сбора сведений о повышении полномочий из журнала аудита.
Для журнала IIS следует выбрать формат файла W3C Extended в IIS 6.0, чтобы записывать как можно больше полей. Для Log Parser приемлемы любые форматы журнала IIS, но формат W3C Extended обеспечивает запись наиболее разнообразной информации. Наличие максимально полной информации полезно, когда возникает необходимость в детальном анализе аномальных событий.
Чтобы настроить протоколирование, следует установить флажок Enable Logging в свойствах Web-узла. Из раскрывающегося меню нужно выбрать формат файла журнала W3C Extended, а затем щелкнуть на кнопке Logging Properties. Должны быть отмечены все поля на вкладке Advanced.
Файлы запросов и вывод результатов Log Parser
При подготовке команд Log Parser удобно вставить запросы SQL в текстовый файл, а затем указать этот текстовый файл в качестве аргумента Log Parser. Преимущество такого подхода — в возможности сохранить сложные запросы для повторного использования в будущем. Исправлять синтаксические ошибки проще, если запросы записаны в Notepad, а не вводятся напрямую в командной строке. Чтобы использовать файл запросов вместе с Log Parser, нужно применять следующий формат команды (запрос SQL содержится в файле query.sql):
logparser file:query.sql
-o:DATAGRID -RTP:-1
 |
| Экран. Выходные результаты Log Parser в формате DataGrid |
Выводить данные удобнее в формате DataGrid, а не напрямую в командной строке. Формат DataGrid полезен, если трудно разобраться в выводе командной строки. Параметр -RTP:-1 указывает, что в окне будут представлены все выходные данные, а не только первые 10 строк (предельная величина по умолчанию). На экране показан вывод DataGrid для простого запроса.
В Log Parser предусмотрено много других режимов вывода кроме DataGrid. Если в компьютере установлены Microsoft Office Web Components, то можно выводить результаты Log Parser в разных форматах — от столбчатых диаграмм до круговых. В данной статье применяется только DataGrid, так как это наиболее доступный формат для пользователей Log Parser.
Важные поля файла журнала
В процессе аудита безопасности журналов IIS необходимо рассмотреть несколько важных полей журнала формата W3C Extended. Рекомендуется настроить журналы IIS для записи всех возможных данных, но поля, приведенные в таблице, — лучшие отправные точки для анализа журнала. Протоколирование всех возможных данных — элементарная предосторожность, хотя используется чаще всего лишь несколько полей. Любое поле может содержать полезные данные, которые помогут определить действия, произведенные при взломе сервера IIS. Полный список полей файла журнала формата W3C Extended можно составить, изучив расширенные параметры протоколирования на вкладке Advanced диалогового окна Logging Properties в свойствах Web-узла.
Извлечение основных статистических данных IIS 6.0
С помощью Log Parser можно быстро собрать основные статистические данные для Web-узлов IIS 6.0. В следующем запросе перечислены наиболее часто запрашиваемые файлы целевого сайта:
—-PAGEHITS.SQL—-
SELECT cs-uri-stem, COUNT(*)
FROM <77038354>
GROUP BY cs-uri-stem
ORDER BY COUNT(*) DESC
—-PAGEHITS.SQL—-
где <77038354> представляет уникальный идентификатор сайта. Web-узел IIS 6.0 по умолчанию всегда имеет идентификатор <1>. В отличие от ранних версий IIS, в IIS 6.0 дополнительные сайты не нумеруются последовательно, поэтому для выяснения номера сайта потребуется провести некоторые изыскания, если не используется Web-узел по умолчанию. При запуске нескольких Web-узлов номер можно выяснить, заглянув в оснастку IIS Manager консоли Microsoft Management Console (MMC) или запустив команду Iisweb /query из командной строки. Благодаря мощному механизму запросов и разнообразным форматам вывода, Log Parser можно рекомендовать как отличный инструмент для детального анализа FTP-, WWW- и SMTP-трафика в сервере IIS.
Поиск аномалий
Один из способов сделать первый шаг для поиска аномалий в журналах событий — проверить коды ошибок. Некоторые коды состояния, особенно с номерами от 400 до 424, могут указывать, что имела место какая-то атака и ее следы зафиксированы в журналах Web-сервера. Следующие запросы выдают список ошибок для IP-адреса:
c-ip Client IP address
sc-status Request status code
sc-substatus Request substatus code
cs-username Client username, if available
cs-method Includes information about HTTP verb used
—-STATUSIPADDRESS.SQL—-
SELECT c-ip, cs-uri-stem,
sc-status, sc-substatus,
COUNT(*)
from <77038354>
WHERE (sc-status BETWEEN 400
and 424)
GROUP BY c-ip, sc-status,
sc-substatus, cs-uri-stem
ORDER BY COUNT(*) DESC
—-STATUSIPADDRESS.SQL—-
Данный запрос формирует список зафиксированных ошибок с номерами от 400 (Bad Request) до 424 (Failed Dependency). Эти ошибки свидетельствуют о каких-то нарушениях, и хотя они не всегда связаны со взломом сервера, проблема заслуживает углубленного анализа. После того как будет установлена частота появления конкретных кодов ошибок, можно приступить к планированию оптимального способа использования Log Parser для сбора дополнительной информации из журналов.
Обнаружение необычных запросов HTTP
Часто свидетельства атаки против Web-узла можно обнаружить, отыскивая необычные команды в запросах HTTP. Как правило, большинство корректных запросов HTTP содержит команды POST или GET. Следующий сценарий выдает сведения о любых командах в журнале формата WC3 Extended, отличных от POST и GET, а также о запросах, извлеченных из Web-сервера, кодах состояния запроса и IP-адресе запрашивающего клиента.
—-UNUSUALVERBS.SQL—-
SELECT c-ip, cs-method,
cs-uri-stem, sc-status,
sc-substatus, COUNT(*)
FROM <1>
WHERE (cs-method NOT IN
(?POST?;?GET?))
GROUP BY c-ip, cs-method,
cs-uri-stem, sc-status,
sc-substatus
ORDER BY COUNT(*) DESC
—-UNUSUALVERBS.SQL—-
Необычные команды могут быть безвредными, но могут оказаться и аномалиями, требующими дальнейшего исследования. Вероятность атаки меньше, когда множественные экземпляры одной команды исходят из многих IP-адресов, чем когда множественные экземпляры команды поступают из одного IP-адреса. Множественные команды из одного IP-адреса, которые не использовал ни один посетитель Web-узла, — тревожный сигнал, который нельзя игнорировать.
Отслеживание активности Web-узла
Если обнаружена аномалия, связанная с конкретным IP-адресом, то этот IP-адрес становится отправной точкой для углубленного анализа журналов. Для этого можно использовать запрос, похожий на следующий:
—-TRACKIP.SQL—-
SELECT cs-username,
cs-uri-stem, sc-status,
sc-substatus
FROM <1>
WHERE c-ip = ?w.x.y.z?
—-TRACKIP.SQL—-
Прежде чем запустить сценарий, следует подставить вместо символов w.x.y.z нужный IP-адрес. Кроме того, необходимо убедиться, что идентификатор узла верен и ведется поиск в нужных журналах. Результаты поиска могут дать дополнительные сведения о действиях подозрительного посетителя Web-сервера.
К делу
В данной статье лишь поверхностно затронуты возможности аудита безопасности IIS 6.0 с использованием Log Parser. Разобравшись в приведенных примерах, можно применить их на Web-сервере предприятия, чтобы генерировать собственные запросы для углубленного анализа журналов и блокирования подозрительных действий.
Орин Томас - сотрудник учебного и сертификационного Web-узла CertTutor.net журнала Windows IT Pro. Имеет сертификаты MCSE, CCNA и CCDA. Томас — соавтор учебного курса MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a Microsoft Windows Server 2003 Network (издательство Microsoft Press). orin@lspace.org