sviluppo-web-qa.it

Query LogParser consigliate per IIS?

Man mano che Stack Overflow cresce, stiamo iniziando a esaminare attentamente i nostri IIS registri per identificare i client HTTP problematici - cose come rogue web spiders , gli utenti che hanno un grande pagina impostata per aggiornarsi ogni secondo, scraper web raschietti scritti male, utenti ingannevoli che cercano di aumentare il conteggio delle pagine di 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.

Utilizzo massimo 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 hits 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
 url colpisce 
 -------------------------------------- ----------- ----- 
/content/img/sf/vote-arrow-down.png 14076 
/content/img/sf/vote- arrow-up.png 14018 

Larghezza di banda superiore e hit 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 utente-agente client 
 ------------- --------------------- ------------------------ --------- ----- 
 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
 hr totbytes client user-agent hit 
 - ------------- ------------------ ----------------------- -------- ---- 
 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 user-agent client 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 il percorso di un IIS, come

c:\working\sologs\u_ex090708.log

Ho fatto molte ricerche sul web per ottenere buone IIS LogParser interrogazioni e ho trovato poco prezioso. Queste 5, sopra, ci hanno aiutato moltissimo a identificare i clienti con problemi seri. Ma mi chiedo: quali sono ci manca?

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

86
Jeff Atwood

Un buon indicatore per le attività di hacking o altri attacchi è il numero di errori all'ora. Lo script seguente restituisce date e ore con più di 25 codici di errore restituiti. 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 Conto 
 ---------- -------- ------ ------ 
 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 
 ... 

La query successiva rileva un numero insolitamente alto 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 Edge (ad esempio escluso l'indirizzo IP di 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
 Data URL Indirizzo IP Hit 
 ---------- -------------------------- --------- --------------- ---- 
 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 
 ... 
19
splattne
6

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.

6
James Skemp

Una cosa che potresti considerare per filtrare il traffico legittimo (e ampliare il tuo ambito di applicazione) è abilitare cs(Cookie) nei tuoi log IIS, aggiungi un po 'di codice che imposta un piccolo cookie usando javascript e aggiungi 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.

6
Adam Brand

Questo ragazzo ha circa una dozzina di domande utili:

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

5
Portman

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 qualsiasi sito non di programmazione, è anche una buona idea cercare nei log per le parole chiave SQL, cose come SELECT, UPDATE, DROP, DELETE e altri stranezze come FROM sys.tables, ORing che insieme e il conteggio tramite IP sembrerebbe utile. 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 esegue script premade. Tendo a vedere .ru, .br, .cz e .cn. Non intendo giudicare, ma in un certo momento tendo a bloccarli. A loro difesa, questi paesi sono generalmente prevalentemente popolati, anche se finora non vedo molto da dire .in, .fr, .us o .au facendo 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

Post scriptum Non riesco a verificare che queste query vengano effettivamente eseguite correttamente. Si prega di modificarli liberamente se devono essere riparati.

4
dlamblin

Questi sono stati tutti trovati qui (che è un'eccellente guida per analizzare il tuo IIS file di log, btw):

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 generato 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 ORDINA PER 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

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.

0
BCS