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


По мере того, как Stack Overflow растет, мы начинаем внимательно изучать журналы 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
клиентский пользовательский агент totbytes hits
------------- ------------------------------------- -------- --------- -----
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 клиент-агент пользователя totbytes
- ------------- ----------------------------------- ------ -------- ----
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 клиент-агент пользователя хиты totbytes
- ------------- ----------------------------------- ------ ---- --------
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, которые вы запускаете на своих серверах? 


86
2017-07-25 11:19


Источник


Ссылка на blog.stackoverflow.com/2009/07/podcast-63 - Brad Gilbert
В запросе на использование полосы пропускания используется ключевое слово DISTINCT. Для чего это? - Jakub Šturc


Ответы:


Хорошим показателем для хакерской активности или других атак является количество ошибок в час. Следующий скрипт возвращает даты и часы, которые имели более 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-адрес URL-адреса URL-адреса URL
---------- ----------------------------------- ----- ---------- ----
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
...

19
2017-07-25 11:47



второй запрос, который мы уже выполнили, - обратите внимание на группировку в нескольких запросах. По IP и User Agent это лучшее из обоих миров, поскольку, если агент пользователя имеет значение null, это то же самое, что и IP, а если нет, это больше информации. - Jeff Atwood
Хорошо, Джефф, добавив, что пользователь-агент имеет смысл. Извините, комбинация плохой кратковременной памяти и расстройства дефицита внимания. :-) - splattne
заменяя having с Limit n может сделать хороший способ настроить первый запрос - BCS


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

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

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


6
2017-07-25 17:26





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

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

Для более точного значения просто выполните СУММА (SC-байт) вместо MUL (Hits, AvgBytes) в качестве обслуживаемых байтов,


6
2017-09-10 13:11





Андерс Лундстрем написала серию статей в блогах, касающихся общих запросов LogParser.

Я использовал их:


6
2017-10-28 14:12





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

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


5
2017-08-09 15:07



И этот парень (я) всегда ищет больше запросов для публикации. - James Skemp


Возможно, вам захочется найти ваши самые длинные запросы (стебли и / или запросы) и те, у которых большинство байтов получено сервером. Я также попробовал бы одну из групп по полученным байтам и 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, ORing, что вместе и подсчет по 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

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


4
2017-07-30 17:06





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

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

logparser -i: FS "SELECT TOP 20 Path, CreationTime from c: \ inetpub \ wwwroot *. * ORDER BY 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 «SELECT TOP 20 Path, LastWriteTime от c: \ inetpub \ wwwroot *. * ORDER BY 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 "SELECT 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 "SELECT DISTINCT date, cs-uri-stem, c-ip, Count () AS Hits FROM ex.log GROUP BY date, c-ip, cs-uri-stem HAVING Hits> 50 ORDER BY Hits 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

3
2017-08-06 20:58



Я посмотрел на них и не нашел их особенно полезными. Они в основном «находят компромисс», и это не наша цель (мы не были скомпрометированы) - Jeff Atwood


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


0
2017-08-06 19:32



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