IIS監視のための推奨LogParserクエリ？
スタックオーバーフローが大きくなるにつれて、IISログを詳しく調べて、問題のあるHTTPクライアント（ rogue web spiders 、大きなページを持っているユーザーなど）を特定し始めています。 1秒ごとに更新するように設定し、不十分に記述された1回限りのWebスクレイパー、ページをインクリメントしようとするトリッキーなユーザーは、無数の回数をカウントします。
いくつかの 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 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
クライアントユーザーエージェントの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による1時間ごとの上位帯域幅
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 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クエリを求めて多くのWeb検索を行ったところ、貴重なものはほとんど見つかりませんでした。上記の5つは、深刻な問題のクライアントを特定するのに非常に役立ちました。しかし、私は疑問に思っています-私たちは何を失っていますか？
IISログ（できればLogParserクエリを使用）をスライスしてダイシングして統計異常を見つけるには、他にどのような方法がありますか？ サーバーで実行する適切な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
結果は次のようになります。
日付時間ステータス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 ...
次のクエリは1つの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 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 ...
AndersLundström は、一般的なLogParserクエリに関する一連のブログ記事を書いています。
私はこれらを使用しています：
申し訳ありませんが、まだコメントできませんので、回答させていただきます。
「URLごとの上位帯域幅の使用」クエリには、小さなバグがあります。ほとんどの場合、ページのリクエストを受け取り、ファイルサイズを掛けても大丈夫ですが、この場合、クエリパラメータに注意を払っていないため、わずかに-非常に不正確な数値。
より正確な値を得るには、MUL（Hits、AvgBytes）as ServedBytesの代わりにSUM（sc-bytes）を実行します。
IISログでcs(Cookie)を有効にし、小さなCookieを設定するコードを追加して、正当なトラフィックを除外（および範囲を拡大）することを検討してください。 JavaScriptを使用して、WHERE cs(Cookie)=''を追加します。
コードが少ないため、手動でCookieを無効にしない限り（ユーザーのごく一部が行う可能性があります）、または実際にそのユーザーがJavaScriptをサポートしないボット（wget、httpclientなど）でない限り、すべてのユーザーにCookieが必要ですなどはJavaScriptをサポートしていません）。
ユーザーが大量のアクティビティを持っているがCookieを受け入れ、JavaScriptを有効にしている場合、正当なユーザーである可能性が高くなります。一方、大量のアクティビティを持っているがCookie/JavaScriptをサポートしていないユーザーを見つけた場合、ボットである可能性が高くなります。
この男には約12の有用なクエリがあります。
最長のリクエスト（ステムまたはクエリ、あるいはその両方）、およびサーバーが受信したバイト数が最も多いリクエストを探すことができます。また、受信したバイトとIPでグループ化したものも試して、特定のリクエスト形式が1つの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のグループのヒットを1時間1分でカウントするか、リクエストするIPを1時間の分でグループ化して、スクリプトである可能性のある定期的に繰り返し発生する訪問があるかどうかを確認します。これは、時間スクリプトによるヒットの小さな変更です。
非プログラミングサイトでは、ログで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
追伸これらのクエリが実際に正しく実行されることを確認できません。修正が必要な場合は自由に編集してください。
これらはすべて見つかりました here （IIS logfiles、btw）を解析するための優れたガイドです）：
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 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
同じページに1日に50回以上ヒットしたIPアドレスを表示します
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
LogParserでそれを行う方法はわかりませんが、「phpMyAdmin」（または他の一般的な脆弱性）などの404を取得するリクエストの文字列を探すことは、スクリプト化された攻撃を特定するための良い方法かもしれません。