题 推荐的IIS监控LogParser查询?


随着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

按网址热门点击

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
网址命中
-------------------------------------------------  - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

IP /用户代理的最高带宽和命中率

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命中
------------- ------------------------------------- -------- --------- -----
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 client user-agent totbytes hits
 -  ------------- ----------------------------------- ------ -------- ----
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 client user-agent命中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

{filename}当然是IIS日志文件的路径,例如

c:\working\sologs\u_ex090708.log

我做了很多网页搜索,查找了很好的IIS LogParser查询,发现很少见。上面的这五个,帮助我们在识别严重问题客户方面做出了巨大贡献。但我想知道 - 我们错过了什么?

还有哪些方法可以对IIS日志进行切片和切块(最好是 使用LogParser查询)挖掘他们的统计异常? 您是否在服务器上运行了任何良好的IIS LogParser查询? 


86
2017-07-25 11:19




参考 blog.stackoverflow.com/2009/07/podcast-63 - Brad Gilbert
在顶部带宽使用情况查询中,有DISTINCT关键字。到底有什么好处呢? - Jakub Šturc


答案:


黑客活动或其他攻击的一个很好的指标是每小时的错误数量。以下脚本返回 超过25个错误代码的日期和小时 回。根据站点上的流量(以及Web应用程序的质量;-))调整值。

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
...

下一个查询检测到 来自一个IP地址的单个URL上的异常大量命中。在此示例中,我选择了500,但您可能必须更改边缘情况的查询(例如,不包括Google London的IP地址;-)。)

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 IPAddress命中
---------- ----------------------------------- ----- ---------- ----
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和用户代理,这是两全其美的,因为如果用户代理为空,则与IP相同,如果不是,那就是更多信息。 - Jeff Atwood
好的杰夫,添加用户代理是有道理的。对不起,短时记忆不良和注意力缺陷障碍的结合。 :-) - splattne
取代 having 用一个 Limit n 可能是调整第一个查询的好方法 - BCS


您可以考虑过滤掉合法流量(并扩大范围)的一件事是启用 cs(Cookie) 在IIS日志中,添加一些使用javascript设置小cookie的代码,然后添加 WHERE cs(Cookie)=''

由于您的代码很少,每个用户都应该拥有一个cookie,除非他们手动禁用cookie(很少有人可能会这样做)或者除非该用户实际上是一个不支持Javascript的机器人(例如,wget,httpclient)等等,不支持Javascript)。

我怀疑如果用户活动量很大,但他们接受cookie并启用了javascript,他们更有可能成为合法用户,而如果你发现活动量很大但没有cookie / javascript支持的用户,他们更可能是一个机器人。


6
2017-07-25 17:26





对不起,还不能发表评论所以我不得不回答。

“网址带宽使用率”查询存在一个小错误。虽然大多数情况下你可以接受页面请求并乘以文件大小,但在这种情况下,由于你没有注意任何查询参数,你会遇到一些问题。 - 非常不准确的数字。

要想获得更准确的价值,请做一个 SUM(SC-字节) 而不是 MUL(Hits,AvgBytes)作为ServedBytes


6
2017-09-10 13:11





AndersLundström 一直在撰写一系列有关常见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关键字也是一个好主意,比如 SELECTUPDATEDROPDELETE 和其他奇怪的事情一样 FROM sys.tables或者将它们组合在一起并通过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 from 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点击从前.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

在一天内显示同一页面超过50次的任何IP地址

logparser“SELECT DISTINCT date,cs-uri-stem,c-ip,Count()AS点击从前.log GROUP BY date,c-ip,cs-uri-stem Hits 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)之类的请求字符串,这些请求可能是识别脚本攻击的好方法。


0
2017-08-06 19:32



目标不是找到那种类型的脚本攻击,而是与带宽和流量相关的不负责任/问题客户端。 - Jeff Atwood
我会说任何试图伤害我的客户都是一个问题客户端,我宁愿不让他们使用我的带宽。 - BCS