随着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 hits avgbyte served ------------------------------------------------- ----- ------- ------- /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 hits ------------------------------------------------- ----- /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
client user-agent totbytes hits ------------- --------------------------------------------- --------- ----- 66.249.68.47 Mozilla/5.0+(compatible;+Googlebot/2.1; 135131089 16640 194.90.190.41 omgilibot/0.3++omgili.com 133805857 6447
按IP /用户代理按小时划分的最高带宽
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 /用户按小时划分的最高点击率代理
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 hits totbytes -- ------------- ----------------------------------------- ---- -------- 10 194.90.190.41 omgilibot/0.3++omgili.com 1503 29070370 12 66.249.68.47 Mozilla/5.0+(compatible;+Googlebot/2.1 1363 13186302
{filename}当然是IIS日志文件的路径，例如
c:\working\sologs\u_ex090708.log 我做了很多网络搜索，以寻找良好的IIS LogParser查询，却发现很少。上面的这5个，极大地帮助我们确定了严重的问题客户。但是我想知道-我们还缺少什么？您是否在服务器上运行任何良好的IIS LogParser查询？
#1 楼
黑客活动或其他攻击的一个很好的指标是每小时错误的数量。以下脚本返回已返回超过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
结果可能是这样的：
Date Hour Status 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
评论
第二个查询，我们已经做过-请注意几个查询中的分组。就IP和用户代理而言，这是两全其美的方法，因为如果用户代理为null，则它与IP相同，否则，这是更多信息。
–杰夫·阿特伍德
09年7月25日在12:50
好的，Jeff，添加用户代理很有意义。抱歉，短时记忆不佳和注意力缺乏症相结合。 :-)
–splattne
09年7月25日13:00
用Limit n替换hading可能是调整第一个查询的好方法
–BCS
09年8月6日在19:27
#2 楼
您可以考虑过滤掉合法流量（并扩大范围）的一件事是在IIS日志中启用cs(Cookie)，添加一些使用javascript设置小cookie的代码，并添加WHERE cs(Cookie)=''。 由于您的代码很少，每个用户都应该有一个cookie，除非他们手动禁用了cookie（一小部分人可能会禁用）或除非该用户实际上是不支持的机器人Javascript（例如wget，httpclient等不支持Javascript）。
我怀疑如果用户的活动量很大，但是他们接受Cookie并启用了JavaScript，则它们是更有可能是合法用户，而如果您发现活动量很大但不支持Cookie / JavaScript的用户，则他们很可能是机器人。
#3 楼
抱歉，目前无法发表评论，所以我不得不回答。“ URL最大带宽使用率”查询存在一个小错误。大多数情况下，您可以接受页面请求并乘以文件大小，但是在这种情况下，由于您不关注任何查询参数，因此您会遇到一些-非常不准确的数字。
要获得更准确的值，只需执行SUM（sc-bytes）而不是MUL（Hits，AvgBytes）作为ServedBytes。
#4 楼
AndersLundström一直在撰写有关LogParser常见查询的一系列博客文章。我一直在使用这些文章：按尺寸发送的前10张图像
LOGPARSER＃5：ASPX上最慢的10页
LOGPARSER＃12：解决由谁引起的500错误？
LOGPARSER＃23：从访问您网站的用户那里获取操作系统版本
#5 楼
这个人有大约十二个有用的查询：http://logparserplus.com/Examples/Queries.aspx
评论
这个人（我）一直在寻找更多要发布的查询。
–詹姆斯·斯肯普（James Skemp）
2011-2-27在19:42
#6 楼
您可能希望查找最长的请求（词根和/或查询）以及服务器接收到的最大字节的请求。我也尝试将接收到的字节和IP分组，以便您查看某个IP是否可能重复一种特定的请求格式。我还要计算一天中一小时和一分钟内请求IP组的匹配次数，或者将请求IP与一小时中的分钟进行分组，以查找是否有可能是脚本的定期重复访问。这将是对按小时数命中脚本的小的修改。其他奇数，例如
SELECT，对它们进行或运算并按IP进行计数似乎很方便。对于包括这些站点的大多数站点，这些单词很少会出现在URI的查询部分中，但是在这里，它们可能合法地出现在URI词干和数据部分中。我喜欢颠倒任何歌曲的IP，只是看看谁在运行预制脚本。我倾向于看到UPDATE，DROP，DELETE和FROM sys.tables。我并不是要判断，但是我倾向于从现在开始阻止他们。在他们的辩护中，这些国家通常是人口最多的地方，尽管到目前为止，我仍然很少说.ru，.br，.cz或.cn这样做。 > PS我无法验证这些查询是否会正确运行。如果需要修复，请自由编辑。#7 楼
这些都在这里找到（这是解析IIS日志文件的绝佳指南，顺便说一句）：您网站上的20个最新文件
logparser -i：FS“选择顶部20路径，来自c：\ inetpub \ wwwroot *。*的CreationTime。* 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“从c：\ inetpub \ wwwroot *。* ORDER BY LastWriteTime DESC订购SELECT TOP 20路径，LastWriteTime” -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个状态代码的文件（以防删除木马） 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“从ex.log GROUP BY日期，c-ip，cs-uri-stem中选择匹配日期，cs-uri-stem，c-ip，Count（）AS匹配> 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
评论
我查看了这些内容，但发现它们没有特别的帮助。他们大多是“找到妥协”，而这并不是我们的目标（我们并未受到损害）
–杰夫·阿特伍德
09年8月7日在8:59
#8 楼
我不知道如何使用LogParser进行操作，但是寻找诸如phpMyAdmin之类的请求字符串（或其他常见漏洞）以获取404可能是识别脚本攻击的好方法。评论
目标不是找到这种类型的脚本攻击，而是与带宽和流量有关的不负责任/有问题的客户端。
–杰夫·阿特伍德
09年8月7日在9:04
我会说任何试图伤害我的客户都是有问题的客户，而我不希望他们使用我的带宽。
–BCS
09年8月7日在17:16
评论
由blog.stackoverflow.com/2009/07/podcast-63引用
在带宽使用率最高的查询中，有DISTINCT关键字。这有什么用？