Empfohlene LogParser-Abfragen für die IIS-Überwachung?

Während der Stapelüberlauf zunimmt, untersuchen wir unsere IIS-Protokolle genau, um problematische HTTP-Clients zu identifizieren - Dinge wie betrügerische Web-Spider , Benutzer, die jede Sekunde eine große Seite aktualisieren müssen, schlecht geschriebene einmalige Web-Scraper, trickreich Benutzer, die versuchen, die Anzahl der Seiten zu erhöhen, zählen zig Mal und so weiter.

Ich habe mir ein paar LogParser- Abfragen ausgedacht , mit denen wir die meisten Unregelmäßigkeiten und Abnormalitäten identifizieren können, wenn wir auf eine IIS-Protokolldatei verweisen.

Höchste Bandbreitennutzung nach 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 geliefert
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Top-Treffer nach 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 trifft
------------------------------------------------- - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Top Bandbreite und Treffer durch 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

Client-Benutzer-Agent-Gesamttreffer
------------- ------------------------------------- -------- --------- -----
66.249.68.47 Mozilla / 5.0 + (kompatibel; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

Spitzenbandbreite pro Stunde nach 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 Gesamttreffer
- ------------- ----------------------------------- ------ -------- ----
9 194.90.190.41 omgilibot / 0.3 ++ omgili.com 30634860 ​​1549
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 29070370 1503

Top Hits pro Stunde von 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

Der Benutzeragent des hr-Clients schlägt insgesamt Byte zu
- ------------- ----------------------------------- ------ ---- --------
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (kompatibel; + Googlebot / 2.1 1363 13186302

Der {Dateiname} wäre natürlich ein Pfad zu einer IIS-Protokolldatei, wie z

c:\working\sologs\u_ex090708.log

Ich habe viele Websuchen nach guten IIS-LogParser-Abfragen durchgeführt und dabei wertvolle Kleinigkeiten gefunden. Diese 5 oben haben uns enorm dabei geholfen, Kunden mit schwerwiegenden Problemen zu identifizieren. Aber ich frage mich - was fehlt uns?

Welche anderen Möglichkeiten gibt es, um die IIS-Protokolle (vorzugsweise mit LogParser-Abfragen ) aufzuschlüsseln und auf statistische Anomalien zu untersuchen? Haben Sie gute IIS LogParser-Abfragen, die Sie auf Ihren Servern ausführen?

Ein guter Indikator für Hacking-Aktivitäten oder andere Angriffe ist die Anzahl der Fehler pro Stunde. Das folgende Skript gibt die Daten und Stunden zurück, für die mehr als 25 Fehlercodes zurückgegeben wurden. Passen Sie den Wert abhängig von der Anzahl der Zugriffe auf der Website (und der Qualität Ihrer Webanwendung ;-)) an.

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

Das Ergebnis könnte ungefähr so ​​aussehen:

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

Die nächste Abfrage erkennt eine ungewöhnlich hohe Anzahl von Treffern auf einer einzelnen URL von einer IP-Adresse . In diesem Beispiel habe ich 500 gewählt, aber Sie müssen möglicherweise die Abfrage für Edge-Cases ändern (ausgenommen die IP-Adresse von beispielsweise 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

Datum URL IPAddress Zugriffe
---------- ----------------------------------- ----- ---------- ----
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
...

Eine Sache, die Sie in Betracht ziehen könnten, um legitimen Datenverkehr herauszufiltern (und Ihren Bereich zu erweitern), ist die Aktivierung cs(Cookie)in Ihren IIS-Protokollen, das Hinzufügen eines kleinen Codes, der mithilfe von Javascript ein kleines Cookie setzt, und das Hinzufügen WHERE cs(Cookie)=''.

Aufgrund Ihres kleinen Codes sollte jeder Benutzer ein Cookie haben, es sei denn, er hat Cookies manuell deaktiviert (was ein kleiner Prozentsatz der Leute tun könnte) oder es ist tatsächlich ein Bot, der kein Javascript unterstützt (z. B. wget, httpclient) etc. unterstützen kein Javascript).

Ich vermute, dass ein Benutzer mit einem hohen Aktivitätsvolumen, der Cookies akzeptiert und Javascript aktiviert hat, eher ein legitimer Benutzer ist, während Sie einen Benutzer mit einem hohen Aktivitätsvolumen, aber ohne Cookie- / Javascript-Unterstützung finden Sie sind eher ein Bot.

Leider kann ich noch keinen Kommentar abgeben, daher bin ich gezwungen zu antworten.

Es gibt einen kleinen Fehler bei der Abfrage "Höchste Bandbreitennutzung nach URL". Während Sie die meiste Zeit in Ordnung sind, Ihre Anforderungen für eine Seite zu beantworten und mit der Dateigröße zu multiplizieren, werden Sie in diesem Fall auf einige geringfügige Probleme stoßen, da Sie keine Abfrageparameter berücksichtigen -sehr ungenaue Zahlen.

Für einen genaueren Wert führen Sie einfach eine SUMME (SC -Bytes) anstelle der MUL (Hits, AvgBytes) als ServedBytes aus .

Anders Lundström hat eine Reihe von Blog-Artikeln zu häufigen LogParser-Abfragen verfasst.

Ich benutze diese:

• LOGPARSER 1: Top 10 Bilder nach Größe gesendet
• LOGPARSER # 5: Top 10 der langsamsten ASPX-Seiten
• LOGPARSER # 12: Beheben Sie, wer Ihre 500 Fehler verursacht.
• LOGPARSER # 23: Erhalten Sie die Betriebssystemversion von Benutzern, die auf Ihre Site zugreifen

Dieser Typ hat ungefähr ein Dutzend nützliche Fragen:

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

Möglicherweise möchten Sie nach Ihren längsten Anforderungen (Stems und / oder Abfragen) und denjenigen mit den meisten vom Server empfangenen Bytes suchen. Ich würde auch versuchen, eine, die nach den empfangenen Bytes und der IP gruppiert, damit Sie sehen können, ob ein bestimmtes Anforderungsformat, das wahrscheinlich von einer IP wiederholt wird.

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

Ich würde auch die Treffer entweder für die Gruppe anfordernder IP für eine Stunde und eine Minute eines Tages zählen oder die anfordernde IP mit der Minute der Stunde gruppieren, um festzustellen, ob es regelmäßig wiederkehrende Besuche gibt, bei denen es sich möglicherweise um Skripte handelt. Dies wäre eine kleine Modifikation des Skripts für Treffer pro Stunde.

Auf allen nicht-Programmierung - Sites, ist Ihre Protokolle für SQL - Schlüsselwörter sucht auch eine gute Idee, Dinge wie SELECT, UPDATE, DROP, DELETEund andere Merkwürdigkeiten wie FROM sys.tables, ORing , die zusammen und Zählen von IP praktisch scheinen. Für die meisten Sites, einschließlich dieser Sites, werden die Wörter selten oder nie im Abfrageteil der URI angezeigt, aber hier werden sie möglicherweise legitimerweise im URI-Stamm und in den Datenteilen angezeigt. Ich mag es, die IPs von Treffern umzukehren, nur um zu sehen, wer vorgefertigte Skripte ausführt. Ich neige dazu , zu sehen .ru, .br, .czund .cn. Ich will nicht urteilen, aber ich neige dazu, sie von nun an zu blockieren. In ihrer Verteidigung, werden diese Länder im Allgemeinen meist bevölkert, obwohl ich mich nicht so weit viel sagen sehen .in, .fr, .usoder .audas gleiche zu tun.

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 Ich kann nicht überprüfen, ob diese Abfragen tatsächlich korrekt ausgeführt werden. Bitte bearbeiten Sie sie frei, wenn sie repariert werden müssen.

Diese wurden alle hier gefunden (was eine hervorragende Anleitung zum Parsen Ihrer IIS-Protokolldateien ist, übrigens):

20 neueste Dateien auf Ihrer Website

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 zuletzt geänderte Dateien

logparser -i: FS "SELECT TOP 20-Pfad, LastWriteTime von 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

Dateien, die zu 200 Statuscodes geführt haben (falls Trojaner gelöscht wurden)

logparser "SELECT DISTINCT TO_LOWERCASE (cs-uri-stem) ALS URL, Count ( ) ALS Treffer VON 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

Zeigen Sie alle IP-Adressen an, die an einem Tag mehr als 50 Mal dieselbe Seite aufgerufen haben

logparser "SELECT DISTINCT date, cs-uri-stamm, c-ip, Count ( ) ALS Treffer VON ex .log GROUP BY date, c-ip, cs-uri-stamm 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

Ich weiß nicht, wie ich das mit LogParser machen soll, aber das Suchen nach Anforderungszeichenfolgen für Dinge wie "phpMyAdmin" (oder andere gängige Fehlerquellen), die 404-Werte erhalten, ist möglicherweise eine gute Möglichkeit, Skriptangriffe zu identifizieren.