it-swarm.com.de

Empfohlene LogParser-Abfragen für IIS Überwachung?

Mit zunehmendem Stapelüberlauf beginnen wir, unsere IIS - Protokolle genau zu untersuchen, um problematische HTTP-Clients zu identifizieren - Dinge wie Rogue Web Spider , Benutzer mit einer großen Anzahl Seitensatz, der jede Sekunde aktualisiert wird, schlecht geschriebene, einmalige Web-Scraper, trickreiche Benutzer, die versuchen, die Seitenzahl zig Mal zu erhöhen, und so weiter.

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

Top-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-Treffer avgbyte serviert 
 ------------------------------------ ------------- ----- ------- ------- 
/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-Treffer 
 ---------------------------------- ----------- ----- 
/content/img/sf/Abstimmung-Pfeil-nach unten.png 14076 
/Inhalt/img/sf/Abstimmung- Pfeil nach oben.png 14018 

Top Bandbreite und Treffer von 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-Totbyte-Treffer 
 ------------- --------------------- ------------------------ --------- ----- 
 66.249.68.47 Mozilla/5.0 + (kompatibel; + Googlebot/2.1; 135131089 16640 
 194.90.190.41 omgilibot/0.3 ++ omgili.com 133805857 6447 

Höchste Bandbreite 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 Totbytes Treffer 
 - ------------- ------------------ ----------------------- -------- ---- 
 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-Treffer 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
 hr Client User-Agent trifft Totbytes 
 - ------------- ------------------ ----------------------- ---- -------- 
 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 nur wenig gefunden. Diese 5 oben haben uns enorm bei der Identifizierung schwerwiegender Problemkunden geholfen. Aber ich frage mich - was sind wir vermissen?

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

86
Jeff Atwood

Ein guter Indikator für Hacking-Aktivitäten oder andere Angriffe ist die Anzahl der Fehler pro Stunde. Das folgende Skript gibt das zurückgegebene Datum und Uhrzeit mit mehr als 25 Fehlercodes zurück. Passen Sie den Wert abhängig vom Verkehrsaufkommen 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 ein ngewöhnlich hohe Anzahl von Treffern auf einer einzelnen URL von einer IP-Adresse. In diesem Beispiel habe ich 500 ausgewählt, aber Sie müssen möglicherweise die Abfrage für Edge-Fälle ändern (z. B. ohne die IP-Adresse von 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 Hits 
 ---------- -------------------------- --------- --------------- ---- 
 24.07.2009 /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
splattne
6

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

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

Für einen genaueren Wert führen Sie einfach ein SUM (sc-bytes) anstelle des MUL (Hits, AvgBytes) as ServedBytes aus.

6
James Skemp

Eine Sache, die Sie in Betracht ziehen könnten, um legitimen Datenverkehr herauszufiltern (und Ihren Bereich zu erweitern), ist die Aktivierung von cs(Cookie) in Ihren IIS -Protokollen). Fügen Sie ein bisschen Code hinzu, der ein kleines Cookie setzt Verwenden Sie Javascript und fügen Sie WHERE cs(Cookie)='' hinzu.

Aufgrund Ihres kleinen Codes sollte jeder Benutzer ein Cookie haben, es sei denn, er hat Cookies manuell deaktiviert (was ein kleiner Prozentsatz der Benutzer möglicherweise tut) oder dieser Benutzer ist tatsächlich ein Bot, der Javascript nicht unterstützt (z. B. wget, httpclient) usw. unterstützen kein Javascript).

Ich vermute, dass ein Benutzer mit einem hohen Aktivitätsvolumen, der jedoch Cookies akzeptiert und Javascript aktiviert hat, eher ein legitimer Benutzer ist, während ein Benutzer mit einem hohen Aktivitätsvolumen, aber ohne Unterstützung für Cookies/Javascript sind sie eher ein Bot.

6
Adam Brand

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

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

5
Portman

Möglicherweise möchten Sie nach Ihren längsten Anforderungen (Stems und/oder Abfragen) und denen mit den meisten vom Server empfangenen Bytes suchen. Ich würde auch versuchen, eine nach den empfangenen Bytes und der IP zu gruppieren, damit Sie sehen können, ob ein bestimmtes Anforderungsformat 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 der anfordernden 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 Änderung am Stunden-Skript.

Auf Websites, die nicht programmiert sind, ist es auch eine gute Idee, Ihre Protokolle nach SQL-Schlüsselwörtern zu durchsuchen, z. B. SELECT, UPDATE, DROP, DELETE und andere Kuriositäten wie FROM sys.tables, ORing zusammen und Zählen nach IP scheint praktisch. Bei den meisten Websites, einschließlich dieser, werden die Wörter selten oder nie im Abfrageteil der URI angezeigt, aber hier werden sie möglicherweise zu Recht im URI-Stamm- und Datenteil angezeigt. Ich mag es, die IPs von Treffern umzukehren, nur um zu sehen, wer vorgefertigte Skripte ausführt. Ich neige dazu, .ru, .br, .cz Und .cn Zu sehen. Ich will nicht urteilen, aber ich neige dazu, sie von nun an zu blockieren. Zu ihrer Verteidigung sind diese Länder im Allgemeinen größtenteils besiedelt, obwohl ich bisher nicht viel von .in, .fr, .us Oder .au Sehen kann. dasselbe machen.

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

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

4
dlamblin

Diese wurden alle gefunden hier (dies ist eine hervorragende Anleitung zum Parsen Ihrer IIS Logdateien, übrigens):

20 neueste Dateien auf Ihrer Website

logparser -i: FS "SELECT TOP 20 Pfad, CreationTime von 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 Path, 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) AS URL, Count () AS Hits FROM ex. log WHERE sc-status = 200 GRUPPE NACH URL BESTELLEN NACH URL" -rtp: - 1

URL                                      Hits
---------------------------------------- -----
/About.asp                               122
/Default.asp                             9823
/downloads/setup.exe                     701
/files.Zip                               1
/Products.asp                            8341
/robots.txt                              2830

Zeigt jede IP-Adresse an, die an einem Tag mehr als 50 Mal auf dieselbe Seite gelangt ist

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
GregD

Ich weiß nicht, wie ich es mit LogParser machen soll, aber wenn ich nach Anforderungszeichenfolgen für Dinge wie "phpMyAdmin" (oder andere gängige Vunerablities) suche, die 404s erhalten, kann dies eine gute Möglichkeit sein, Skriptangriffe zu identifizieren.

0
BCS