Richieste LogParser consigliate per il monitoraggio IIS?

Man mano che Stack Overflow cresce, stiamo iniziando a esaminare da vicino i nostri registri IIS per identificare i client HTTP problematici - cose come spider web disonesti , utenti che hanno una grande pagina impostata per aggiornarsi ogni secondo, scraper web raschietti scritti male, trucchi gli utenti che provano ad aumentare il conteggio delle pagine un milione di volte e così via.

Ho escogitato alcune query LogParser che ci aiutano a identificare la maggior parte delle stranezze e delle anomalie quando indicato a un file di registro IIS.

Migliore utilizzo della larghezza di banda per 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 colpisce avgbyte servito
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Principali risultati per 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

colpi url
------------------------------------------------- - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Larghezza di banda e risultati migliori per 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

hit totbyte client utente-agente
------------- ------------------------------------- -------- --------- -----
66.249.68.47 Mozilla / 5.0 + (compatibile; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

Larghezza di banda massima per ora per 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

hit totbytes client utente agente utente
- ------------- ----------------------------------- ------ -------- ----
9 194.90.190.41 omgilibot / 0.3 ++ omgili.com 30634860 ​​1549
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 29070370 1503

Principali risultati per ora per 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 colpisce totbytes
- ------------- ----------------------------------- ------ ---- --------
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (compatibile; + Googlebot / 2.1 1363 13186302

Il {nomefile} ovviamente sarebbe un percorso per un file di registro IIS, come ad esempio

c:\working\sologs\u_ex090708.log

Ho fatto molte ricerche sul web per trovare buone query su IIS LogParser e ho trovato poco prezioso. Questi 5, sopra, ci hanno aiutato moltissimo a identificare i clienti con problemi seri. Ma mi chiedo: cosa ci manca?

Quali altri modi ci sono per tagliare e tagliare i log IIS (preferibilmente con le query LogParser ) per estrarli per anomalie statistiche? Hai qualche buona query IIS LogParser che esegui sui tuoi server?

Un buon indicatore per le attività di hacking o altri attacchi è il numero di errori all'ora. Lo script seguente restituisce le date e le ore in cui sono stati restituiti più di 25 codici di errore . Regola il valore in base alla quantità di traffico sul sito (e alla qualità della tua applicazione 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

Il risultato potrebbe essere qualcosa del genere:

Data Ora Stato Errore Conteggio
---------- -------- ------ ------
24/07/2009 18:00:00 404187
17-07-2009 13:00:00 500 99
21-07-2009 21:00:00 404 80
2009-07-03 04:00:00 404 45
...

La query successiva rileva un numero insolitamente elevato di hit su un singolo URL da un indirizzo IP . In questo esempio ho scelto 500, ma potrebbe essere necessario modificare la query per i casi limite (escluso l'indirizzo IP di Google London, ad esempio ;-).)

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

Hit URL indirizzo IP data
---------- ----------------------------------- ----- ---------- ----
24/07/2009 /Login.aspx 111.222.111.222 1889
12/07/2009 /AccountUpdate.aspx 11.22.33.44 973
19/07/2009 /Login.aspx 123.231.132.123 821
21-07-2009 /Admin.aspx 44.55.66.77 571
...

Una cosa che potresti considerare per filtrare il traffico legittimo (e ampliare il tuo ambito di applicazione) è quella di abilitare cs(Cookie)nei tuoi log IIS, aggiungere un po 'di codice che imposta un piccolo cookie usando JavaScript e aggiungere WHERE cs(Cookie)=''.

A causa del tuo piccolo bit di codice, ogni utente dovrebbe avere un cookie a meno che non disabilitasse manualmente i cookie (cosa che potrebbe fare una piccola percentuale di persone) o a meno che quell'utente non sia effettivamente un bot che non supporta Javascript (ad esempio, wget, httpclient , ecc. non supportano Javascript).

Sospetto che se un utente ha un volume elevato di attività, ma accetta i cookie e ha javascript abilitato, è più probabile che sia un utente legittimo, mentre se trovi un utente con un volume elevato di attività ma nessun supporto per cookie / javascript , hanno maggiori probabilità di essere un bot.

Siamo spiacenti, non posso ancora commentare, quindi sono costretto a rispondere.

C'è un bug minore con la query "Utilizzo della larghezza di banda superiore per URL". Mentre la maggior parte delle volte staresti bene prendendo le tue richieste per una pagina e moltiplicandole per le dimensioni del file, in questo caso, poiché non stai prestando attenzione a nessun parametro di query, ti imbatterai in alcuni -molto numeri imprecisi.

Per un valore più accurato, basta fare un SUM (sc-bytes) invece del MUL (Hits, AvgBytes) come ServedBytes .

Anders Lundström ha scritto una serie di articoli di blog riguardanti le query più comuni di LogParser.

Ho usato questi:

• LOGPARSER # 1: le 10 migliori immagini per dimensione inviate
• LOGPARSER # 5: le 10 pagine ASPX più lente
• LOGPARSER # 12: risolvere chi sta causando i tuoi 500 errori?
• LOGPARSER # 23: ottieni la versione del sistema operativo dagli utenti che colpiscono il tuo sito

Questo ragazzo ha circa una dozzina di domande utili:

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

Potresti voler cercare le tue richieste più lunghe (stems e / o query) e quelle con la maggior parte dei byte ricevuti dal server. Proverei anche uno che raggruppa per byte ricevuti e IP, in modo da poter vedere se un particolare formato di richiesta che è probabilmente ripetuto da un 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

Conterrei anche i risultati per il gruppo di IP richiedente per un'ora e un minuto di un giorno, o raggrupperei l'IP richiedente con il minuto dell'ora per scoprire se ci sono visite periodiche ricorrenti che possono essere script. Questa sarebbe una piccola modifica sullo script hit by hour.

Su altri siti non-programmazione, ricerca i tuoi log per le parole chiave SQL è anche una buona idea, le cose come SELECT, UPDATE, DROP, DELETEe altre stranezze, come FROM sys.tables, ORing che insieme e il conteggio IP sembrerebbe a portata di mano. Per la maggior parte dei siti inclusi questi, le parole apparirebbero raramente nella porzione di query dell'URI, ma qui potrebbero apparire legittimamente nella radice dell'URI e nelle parti di dati. Mi piace invertire gli IP di qualsiasi hit solo per vedere chi sta eseguendo script premade. Io tendo a vedere .ru, .br, .cze .cn. Non intendo giudicare, ma in un certo momento tendo a bloccarli. A loro difesa, questi paesi sono in genere per lo più popolate, anche se finora non vedo molto di dire .in, .fr, .uso .aufacendo lo stesso.

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 Non riesco a verificare che queste query vengano effettivamente eseguite correttamente. Si prega di modificarli liberamente se devono essere riparati.

Questi sono stati tutti trovati qui (che è una guida eccellente per l'analisi dei file di log IIS, tra l'altro):

20 file più recenti sul tuo sito web

logparser -i: FS "SELEZIONA TOP 20 Path, CreationTime da c: \ inetpub \ wwwroot *. * ORDINA PER 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 file modificati più di recente

logparser -i: FS "SELEZIONA TOP 20 Path, LastWriteTime da c: \ inetpub \ wwwroot *. * ORDINA PER 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

File che hanno prodotto 200 codici di stato (nel caso in cui i trojan fossero eliminati)

logparser "SELEZIONA DISTINCT TO_LOWERCASE (cs-uri-stem) AS URL, Count ( ) AS Hits FROM ex .log DOVE sc-status = 200 Raggruppa per URL ORDINA PER URL" -rtp: -1

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

Mostra qualsiasi indirizzo IP che ha colpito la stessa pagina più di 50 volte in un solo giorno

logparser "SELEZIONA DISTINCT data, 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

Non so come farlo con LogParser ma cercare stringhe di richieste per cose come "phpMyAdmin" (o altre vunerablities comuni) che ottengono 404s potrebbe essere un buon modo per identificare gli attacchi con script.