Рекомендуемые запросы LogParser для мониторинга IIS?

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

Я придумал несколько запросов LogParser, которые помогают нам идентифицировать большинство странностей и отклонений при указании на файл журнала IIS.

Максимальное использование полосы пропускания по URL

SELECT top 50 DISTINCT 
SUBSTR(TO_LOWERCASE(cs-uri-stem), 0, 55) AS Url, 
Count(*) AS Hits, 
AVG(sc-bytes) AS AvgBytes, 
SUM(sc-bytes) as ServedBytes 
FROM {filename} 
GROUP BY Url 
HAVING Hits >= 20 
ORDER BY ServedBytes DESC

URL-адреса хиты Avgbyte служил
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Самые популярные хиты по URL

SELECT TOP 100 
cs-uri-stem as Url, 
COUNT(cs-uri-stem) AS Hits 
FROM {filename} 
GROUP BY cs-uri-stem 
ORDER BY COUNT(cs-uri-stem) DESC

хиты URL
------------------------------------------------- - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Максимальная пропускная способность и хиты по IP / User-Agent

SELECT TOP 30
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
Sum(sc-bytes) AS TotalBytes, 
Count(*) as Hits 
FROM {filename} 
group by c-ip, cs(User-Agent) 
ORDER BY TotalBytes desc

клиентский агент-клиент насчитывает хиты
------------- ------------------------------------- -------- --------- -----
66.249.68.47 Mozilla / 5.0 + (совместимо; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

Максимальная пропускная способность по часам по IP / User-Agent

SELECT TOP 30
TO_STRING(time, 'h') as Hour, 
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
Sum(sc-bytes) AS TotalBytes, 
count(*) as Hits 
FROM {filename} 
group by c-ip, cs(User-Agent), hour 
ORDER BY sum(sc-bytes) desc

hr клиентский пользовательский агент хиты всего
- ------------- ----------------------------------- ------ -------- ----
9 194.90.190.41 omgilibot / 0.3 ++ omgili.com 30634860 ​​1549
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 29070370 1503

Топ попаданий по часам по IP / User-Agent

SELECT TOP 30
TO_STRING(time, 'h') as Hour, 
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
count(*) as Hits, 
Sum(sc-bytes) AS TotalBytes 
FROM {filename} 
group by c-ip, cs(User-Agent), hour 
ORDER BY Hits desc

Клиентский пользовательский агент hr достигает тотбайтов
- ------------- ----------------------------------- ------ ---- --------
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (совместимо; + Googlebot / 2.1 1363 13186302

{Имя_файла}, конечно, будет путем к файлу журнала IIS, таким как

c:\working\sologs\u_ex090708.log

Я сделал много поисков в Интернете для хороших запросов IIS LogParser и нашел очень мало. Эти 5 выше очень помогли нам в выявлении серьезных проблемных клиентов. Но мне интересно - чего нам не хватает?

Какие есть еще способы нарезать и нарезать журналы IIS (желательно с запросами LogParser ), чтобы найти их для статистических аномалий? Есть ли у вас хорошие запросы IIS LogParser, которые вы запускаете на своих серверах?

Хорошим показателем для взлома активностей или других атак является количество ошибок в час. Следующий скрипт возвращает даты и часы, когда было возвращено более 25 кодов ошибок . Отрегулируйте значение в зависимости от объема трафика на сайте (и качества вашего веб-приложения ;-)).

SELECT date as Date, QUANTIZE(time, 3600) AS Hour, 
       sc-status as Status, count(*) AS ErrorCount
FROM   {filename} 
WHERE  sc-status >= 400 
GROUP BY date, hour, sc-status 
HAVING ErrorCount > 25
ORDER BY ErrorCount DESC

Результат может выглядеть примерно так:

Дата Час Статус ErrorCount
---------- -------- ------ ------
2009-07-24 18:00:00 404 187
2009-07-17 13:00:00 500 99
2009-07-21 21:00:00 404 80
2009-07-03 04:00:00 404 45
...

Следующий запрос обнаруживает необычно большое количество обращений к одному URL-адресу с одного IP-адреса . В этом примере я выбрал 500, но вам, возможно, придется изменить запрос для крайних случаев (исключая, например, IP-адрес Google London ;-).)

SELECT DISTINCT date AS Date, cs-uri-stem AS URL,
      c-ip AS IPAddress, Count(*) AS Hits
FROM  {filename}
GROUP BY date, c-ip, cs-uri-stem
HAVING Hits > 500
ORDER BY Hits Desc

Дата URL IP-адрес Хиты
---------- ----------------------------------- ----- ---------- ----
2009-07-24 /Login.aspx 111.222.111.222 1889
2009-07-12 /AccountUpdate.aspx 11.22.33.44 973
2009-07-19 /Login.aspx 123.231.132.123 821
2009-07-21 /Admin.aspx 44.55.66.77 571
...

Одна вещь, которую вы могли бы рассмотреть, чтобы отфильтровать законный трафик (и расширить область действия), это включить cs(Cookie)в журналы IIS, добавить немного кода, который устанавливает небольшой cookie, используя javascript, и добавить WHERE cs(Cookie)=''.

Из-за небольшого количества кода у каждого пользователя должны быть файлы cookie, если они не отключили файлы cookie вручную (что может сделать небольшой процент пользователей) или если этот пользователь на самом деле не бот, который не поддерживает Javascript (например, wget, httpclient) и т. д. не поддерживают Javascript).

Я подозреваю, что если у пользователя высокий уровень активности, но он принимает файлы cookie и имеет включенный javascript, он, скорее всего, будет законным пользователем, тогда как если вы обнаружите пользователя с большим объемом активности, но без поддержки cookie / javascript , они, скорее всего, будут ботом.

Извините, пока не могу комментировать, поэтому я вынужден ответить.

Есть небольшая ошибка с запросом «Максимальное использование полосы пропускания по URL». Хотя большую часть времени вы будете в порядке, принимая ваши запросы на страницу и умножая их на размер файла, в этом случае, поскольку вы не обращаете внимания на какие-либо параметры запроса, вы столкнетесь с некоторыми очень неточные цифры.

Для более точного значения просто используйте SUM (sc-bytes) вместо MUL (Hits, AvgBytes) как ServedBytes .

Андерс Лундстрем (Anders Lundström) пишет серию статей в блогах, посвященных распространенным запросам LogParser.

Я использовал это:

• LOGPARSER # 1: отправлено 10 лучших изображений по размеру
• LOGPARSER # 5: 10 самых медленных ASPX-страниц
• LOGPARSER # 12: Устраните, кто вызывает ваши 500 ошибок?
• LOGPARSER # 23: Получить версию ОС от пользователей, попавших на ваш сайт

У этого парня около десятка полезных запросов:

http://logparserplus.com/Examples/Queries.aspx

Возможно, вы захотите найти ваши самые длинные запросы (основы и / или запросы), а также те, у которых наибольшее количество байтов получено сервером. Я бы также попробовал тот, который группирует по полученным байтам и IP, чтобы вы могли увидеть, есть ли определенный формат запроса, который, вероятно, повторяется одним IP.

SELECT TOP 30
cs-uri-stem,
cs-uri-query,
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
cs-bytes,
c-ip,
FROM {filename} 
WHERE cs-uri-stem != '/search'
ORDER BY LEN(cs-uri-query) desc

SELECT TOP 30
COUNT(*) AS Hits
cs-uri-stem,
cs-uri-query,
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
cs-bytes,
c-ip,
FROM {filename} 
GROUP BY c-ip, cs(User-Agent), cs-bytes 
ORDER BY Hits desc

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

На любых не-программировании сайтов, поиск журналов для ключевых слов SQL также хорошая идея, таких вещи , как SELECT, UPDATE, DROP, DELETEи другие странности , как FROM sys.tables, что вместе операция OR и подсчет голосов по IP могут показаться полезными. Для большинства сайтов, включая эти, слова редко, если вообще появляются, появляются в части запроса URI, но здесь они могут на законных основаниях появляться в части URI и частях данных. Мне нравится менять IP-адреса любых хитов, чтобы посмотреть, кто запускает готовые скрипты. Я склонен видеть .ru, .br, .czи .cn. Я не хочу судить, но отчасти склонен их блокировать. В своей защите, эти страны , как правило , в основном заселены, хотя я до сих пор я не вижу много скажу .in, .fr, .usили .auделать то же самое.

SELECT TOP 30
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
cs-uri-stem,
LOWER(cs-uri-query) AS q,
count(*) as Hits,
SUM(sc-bytes) AS BytesSent,
SUM(cs-bytes) AS BytesRecv
FROM {filename} 
WHERE q like '%select%' OR q like '%sys.tables%' OR etc... 
GROUP BY c-ip, cs(User-Agent) 
ORDER BY Hits desc

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

Все они были найдены здесь (это отличное руководство для анализа ваших лог файлов IIS, кстати):

20 новейших файлов на вашем сайте

logparser -i: FS "ВЫБЕРИТЕ TOP 20 Path, CreationTime из c: \ inetpub \ wwwroot *. * ЗАКАЗАТЬ ПО CreationTime DESC" -rtp: -1

Path                                                        CreationTime
----------------------------------------------------------- ------------------
c:\inetpub\wwwroot\Default.asp                              6/22/2003 6:00:01
c:\inetpub\wwwroot\About.asp                                6/22/2003 6:00:00
c:\inetpub\wwwroot\global.asa                               6/22/2003 6:00:00
c:\inetpub\wwwroot\Products.asp                             6/22/2003 6:00:00

20 самых последних измененных файлов

logparser -i: FS "ВЫБЕРИТЕ TOP 20 Path, LastWriteTime из c: \ inetpub \ wwwroot *. * ЗАКАЗАТЬ ПО LastWriteTime DESC" -rtp: -1

Path                                                        LastWriteTime
----------------------------------------------------------- ------------------
c:\inetpub\wwwroot\Default.asp                              6/22/2003 14:00:01
c:\inetpub\wwwroot\About.asp                                6/22/2003 14:00:00
c:\inetpub\wwwroot\global.asa                               6/22/2003 6:00:00
c:\inetpub\wwwroot\Products.asp                             6/22/2003 6:00:00

Файлы, которые дали 200 кодов состояния (в случае удаления троянов)

logparser "ВЫБЕРИТЕ DISTINCT TO_LOWERCASE (cs-uri-stem) AS URL, Count ( ) AS Hits FROM ex .log WHERE sc-status = 200 GROUP BY URL ORDER BY URL" -rtp: -1

URL                                      Hits
---------------------------------------- -----
/About.asp                               122
/Default.asp                             9823
/downloads/setup.exe                     701
/files.zip                               1
/Products.asp                            8341
/robots.txt                              2830

Показать любой IP-адрес, который посещал одну и ту же страницу более 50 раз за один день

logparser "ВЫБЕРИТЕ DISTINCT date, cs-uri-stem, c-ip, Count ( ) AS Хиты ОТ ex .log GROUP BY date, c-ip, cs-uri-stem HAVING Хиты> 50 ЗАКАЗАТЬ ПО ХИТАМ Desc" -rtp: -1

date       cs-uri-stem                         c-ip            Hits
---------- ----------------------------------- --------------- ----
2003-05-19 /Products.asp                       203.195.18.24   281
2003-06-22 /Products.asp                       210.230.200.54  98
2003-06-05 /Products.asp                       203.195.18.24   91
2003-05-07 /Default.asp                        198.132.116.174 74

Я не знаю, как это сделать с LogParser, но поиск строк запросов для таких вещей, как «phpMyAdmin» (или других распространенных уязвимостей), которые получают 404, может быть хорошим способом выявления атак по сценарию.