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


86

Коли переповнення стека зростає, ми починаємо уважно придивлятися до наших журналів 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 звертається до авгбайта
------------------------------------------------- - ---- ------- -------
/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, які ви запускаєте на своїх серверах?



У верхньому запиті використання пропускної здатності є ключове слово DISTINCT. Для чого це добре?
Якуб Штурч

Відповіді:


19

Хорошим показником для злому активізації чи інших атак є кількість помилок на годину. Наступний скрипт повертає дати та години, у яких було повернуто більше 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

Результат може бути приблизно таким:

Дата Помилка статусу години дати
---------- -------- ------ ------
24.07.2009 18:00:00 404 187
17.07.2009 13:00:00 500 99
21.07.2009 21:00:00 404 80
2009-07-03 04:00:00 404 45
...

Наступний запит виявляє незвично велику кількість звернень по одній URL-адресі з однієї IP-адреси . У цьому прикладі я вибрав 500, але вам, можливо, доведеться змінити запит для кращих справ (за винятком IP-адреси Google Лондона, наприклад ;-).)

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 дата звернення IPAdress
---------- ----------------------------------- ----- ---------- ----
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
...

другий запит, який ми вже робимо - відзначимо групування за кількома запитами. За IP-адресою та Користувачем-агентом, це найкраще з обох світів, оскільки якщо User Agent недійсний, це те саме, що і IP, а якщо ні, то це додаткова інформація.
Джефф Етвуд

Гаразд, Джефф, додавання користувача-агента має сенс. Вибачте, поєднання поганої короткочасної пам’яті та розладу дефіциту уваги. :-)
splattne

заміна havingз Limit nможе зробити хороший спосіб , щоб налаштуватися на перший запит
BCS

6

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

Через ваш невеликий шматочок коду кожен користувач повинен мати файл cookie, якщо він не відключив файли cookie вручну (що може зробити невеликий відсоток людей) або якщо цей користувач насправді не бот, який не підтримує Javascript (наприклад, wget, httpclient тощо не підтримують Javascript).

Я підозрюю, що якщо користувач має великий обсяг активності, але він приймає файли cookie та увімкнено JavaScript, вони, швидше за все, є законним користувачем, тоді як якщо ви знайдете користувача з великим обсягом активності, але немає підтримки cookie / javascript , вони швидше є ботом.


6

Вибачте, поки не можу коментувати, тому я змушений відповідати.

Існує незначна помилка із запитом "Використання пропускної здатності за URL-адресою". Хоча більшу частину часу вам буде добре приймати запити на сторінку та помножувати на розмір файлу, в цьому випадку, оскільки ви не звертаєте уваги ні на які параметри запиту, ви збираєтеся зіткнутися з деякими -все неточні числа.

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


6


4

Можливо, ви хочете шукати найдовші запити (стебла та / або запити), а також ті, що мають більшість байтів, отриманих сервером. Я б також спробував один, який групується за отриманими байтами та 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 Я не можу перевірити, чи справді ці запити працювали правильно. Будь ласка, редагуйте їх вільно, якщо вони потребують виправлення.


3

Усі вони були знайдені тут (що є чудовим посібником для аналізу ваших журналів IIS, btw):

20 найновіших файлів на вашому веб-сайті

logparser -i: FS "ВИБІР ТОП 20 Шлях, 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 "ВИБІР ТОП 20 Шлях, 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 "ВИБІРТЕ РОЗПОЛУЧЕННЯ ДО_LOWERCASE (cs-uri-stem) AS URL, Count ( ) ЯК ВІДПРИЄМИ З EX .log WHERE sc-status = 200 ГРУПА ЗА URL-ЗАМОВЛЕННЯ ЗА 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 "ВИБРАТИ ДИСТАНТУВАТИ дату, cs-uri-stem, c-ip, Count ( ) ЯК Перегляди з EX .log ГРУПИ за датою, c-ip, cs-uri-stem ВІДПРАВЛЕННЯ Хітів> 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

Я переглянув це і не вважав їх особливо корисними. Вони здебільшого "знаходять компроміс", і це насправді не наша мета (ми не були піддані компромісу)
Джефф Етвуд

0

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


мета полягає не у пошуку скриптованих атак такого типу, а у безвідповідальних / проблемних клієнтів, пов’язаних із пропускною здатністю та трафіком.
Джефф Етвуд

2
Я б сказав, що будь-який клієнт, Який намагається заподіяти мені шкоду, - це проблемний клієнт, і я вважаю за краще не використовувати їх, використовуючи свою пропускну здатність.
BCS
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.