Soru IIS izleme için önerilen LogParser sorguları?


Yığın Taşması büyüdükçe, sorun HTTP istemcilerini tanımlamak için IIS günlüklerimize yakından bakmaya başlıyoruz - dolandırıcı web örümcekler, her sayfa yenilemek için ayarlanmış büyük bir sayfa olan kullanıcılar, kötü yazılmış tek seferlik web kazıyıcıları, sayfa artışını artırmaya çalışan hileci kullanıcılar, bir zilyon kez sayılırlar ve benzerleri.

Birkaç tane ile geldim LogParser IIS günlük dosyasına işaret ettiğinde, tuhaflık ve anormalliklerin çoğunu tanımlamamıza yardımcı olan sorgular.

URL'ye göre en üst bant genişliği kullanımı

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, avgbyte hizmetine başladı
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

URL'ye göre en iyi isabetler

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

IP / Kullanıcı Aracısı tarafından en iyi bant genişliği ve hit

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
istemci kullanıcı aracısı totbytes isabetleri
------------- ------------------------------------- -------- --------- -----
66.249.68.47 Mozilla / 5.0 + (uyumlu; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

IP / Kullanıcı Aracına göre saat başı en üst bant genişliği

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 istemcisi kullanıcı-aracı totbytes isabetleri
- ------------- ----------------------------------- ------ -------- ----
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 / Kullanıcı Aracına göre en çok saat başı isabetler

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 istemcisi kullanıcı aracısı, totbytes vurur
- ------------- ----------------------------------- ------ ---- --------
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (uyumlu; + Googlebot / 2.1 1363 13186302

Elbette, {dosyaadı}, bir IIS günlük dosyasına giden bir yol olacaktır.

c:\working\sologs\u_ex090708.log

İyi bir IIS LogParser sorgusu için çok fazla web araması yaptım ve çok değerli buldum. Yukarıdaki 5, ciddi sorunlu müşterileri belirlemede muazzam bir şekilde yardımcı oldular. Ama merak ediyorum - ne kaçırıyoruz?

IIS günlüklerini dilimlemek ve bölmek için başka hangi yollar vardır? LogParser sorguları ile) istatistiksel anomaliler için onları mayınlı mı? Sunucularınızda çalıştırdığınız iyi bir IIS LogParser sorgunuz var mı? 


86
2017-07-25 11:19


Menşei


Tarafından başvurulan blog.stackoverflow.com/2009/07/podcast-63 - Brad Gilbert
Üst bant genişliği kullanım sorgusunda DISTINCT anahtar sözcüğü var. Bu ne için iyi? - Jakub Šturc


Cevaplar:


Aktiviteleri veya diğer saldırıları kesmek için iyi bir gösterge, saat başına düşen hataların sayısıdır. Aşağıdaki komut dosyası döndürür 25'ten fazla hata kodu içeren tarihler ve saatler iade. Sitedeki trafik miktarına (ve web uygulamanızın kalitesine ;-)) bağlı olarak değeri ayarlayın.

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

Sonuç şöyle bir şey olabilir:

Tarih Saat Durumu 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
...

Bir sonraki sorgu bir Bir IP adresinden tek bir URL’de olağandışı sayıda isabet sayısı. Bu örnekte 500'ü seçtim, ancak kenar durumları için sorguyu değiştirmeniz gerekebilir (örneğin Google Londra’nın IP adresi hariç ;-)).

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
Tarih URL'si IPAdresi Hits
---------- ----------------------------------- ----- ---------- ----
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
2017-07-25 11:47



ikinci sorgu, zaten yapıyoruz - birkaç sorguda gruplandırmayı not edin. IP ve Kullanıcı Aracısı tarafından, bu her iki dünyanın en iyisidir, çünkü Kullanıcı Aracısı boşsa, IP ile aynıdır ve değilse, daha fazla bilgi. - Jeff Atwood
Tamam, Jeff, kullanıcı aracısını eklemek mantıklı. Üzgünüz, kısa süreli hafıza ve Dikkat Eksikliği Bozukluğu'nun bir kombinasyonu. :-) - splattne
değiştiriliyor having Birlikte Limit n İlk sorguyu ayarlamanın iyi bir yolu olabilir - BCS


Meşru trafiği filtrelemek için göz önünde bulundurmanız gereken bir şey (ve kapsamınızı genişletmek) cs(Cookie) IIS günlüklerinizde javascript kullanarak küçük bir çerez ayarlayan bir kod ekleyin ve WHERE cs(Cookie)=''.

Küçük kod kodunuzdan dolayı, her kullanıcının çerezleri el ile devre dışı bırakmadıkça (ki bu da insanların az bir kısmını yapabilir) veya kullanıcı aslında Javascript'i desteklemeyen bir bot olmadıkça (örneğin, wget, httpclient) bir çerez içermelidir. vb Javascript desteklemiyor).

Bir kullanıcının yüksek bir etkinlik hacmine sahip olduğu, ancak çerezleri kabul ettikleri ve javascript'in etkin olduğu şüphesiyle, yüksek bir etkinlik hacmine sahip ancak çerez / javascript desteğine sahip olmayan bir kullanıcı bulursanız, bunların meşru bir kullanıcı olma olasılığı daha yüksektir. Bot olma olasılığı daha yüksektir.


6
2017-07-25 17:26





Üzgünüz, henüz yorum yapamam, bu yüzden cevap vermek zorunda kaldım.

'URL'ye göre en iyi bant genişliği kullanımı' sorgusu olan küçük bir hata var. Çoğu zaman bir sayfa için isteklerinizi almanız ve dosya boyutuna göre çarpmanız yeterli olurken, bu durumda, herhangi bir sorgu parametresine dikkat etmediğinizden, birazcık -çok yanlış sayı.

Daha doğru bir değer için, sadece bir TOPLAM (sc-bayt) onun yerine MUL (Hits, AvgBytes) ServedBytes olarak.


6
2017-09-10 13:11





Anders Lundström yaygın LogParser sorgulamaları ile ilgili bir dizi blog yazısı yazmaktadır.

Bunları kullanıyorum:


6
2017-10-28 14:12





Bu adamın yaklaşık bir düzine yararlı sorusu var:

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


5
2017-08-09 15:07



Ve o adam (ben) her zaman gönderilecek daha fazla sorgu arıyor. - James Skemp


En uzun isteklerinizi (kaynak ve / veya sorgular) ve sunucu tarafından alınan baytların çoğunu aramak isteyebilirsiniz. Ayrıca, alınan baytlar ve IP tarafından bu grupları deneyebilirim, böylece bir IP tarafından tekrarlanan belirli bir istek formatının olup olmadığını görebilirsiniz.

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

Ayrıca, bir gün ve dakika için IP isteme grubunun isabetlerini de sayabilirim veya komut dosyası olabilecek düzenli tekrar eden ziyaretler olup olmadığını bulmak için saatin dakikasıyla istekte bulunan IP'yi gruplandırırdım. Bu, saat betiğine göre isabetlerde küçük bir değişiklik olacaktır.

Herhangi bir programlama olmayan sitede, SQL anahtar kelimelerinizin günlüklerini aramak da iyi bir fikirdir. SELECT, UPDATE, DROP, DELETE ve diğer gariplikler gibi FROM sys.tables, ORing'in birlikte ve IP ile sayılması kullanışlı görünebilir. Bunların dahil olduğu çoğu site için, URI'nin sorgu kısmında hiç görünmüyorsa, kelimeler nadiren görülür, ancak burada URI sapı ve veri bölümlerinde yasal olarak görünebilir. Önceden hazırlanmış komut dosyalarını kimin çalıştırdığını görmek için herhangi bir isabetin IP'lerini tersine çevirmeyi seviyorum. Görmeye eğilimliyim .ru, .br, .cz ve .cn. Ben yargılanmak istemiyorum ama onlardan sonra onları engelleme eğilimindeyim. Onların savunmasında, bu ülkeler genellikle daha çok nüfusa sahipler. .in, .fr, .us veya .au aynısını yapıyor.

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

Not; Bu sorguların doğru şekilde çalışacağını doğrulayamıyorum. Sabitlemeye ihtiyaç duyarlarsa lütfen özgürce düzenleyin.


4
2017-07-30 17:06





Bunların hepsi bulundu İşte (IIS günlük dosyalarınızı ayrıştırmak için mükemmel bir kılavuzdur, btw):

Sitenizde en yeni 20 dosya

logparser -i: FS "ÜST 20 Yolu SEÇİN, C: \ inetpub \ wwwroot * 'dan CreationTime *. * CreationTime DESC" SIRASI "-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

Son değiştirilen 20 dosya

logparser -i: FS "ÜST 20 Yolu SEÇİN, LastWriteTime c: \ inetpub \ wwwroot *. * SIRALANMA SONWriteTime 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 durum koduyla sonuçlanan dosyalar (Truva atları silinirse)

logparser "SELECT DISTINCT TO_LOWERCASE (cs-uri-stem) AS URL, Sayım () AS.log WHERE sc-status = URL'YE GÖRE URL SIPARIŞLA 200 GRUP "-rtp: -1

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

Aynı sayfaya giren tüm IP adreslerini tek bir günde 50'den fazla kez göster

logparser "SELECT DISTINCT tarih, cs-uri-stem, c-ip, Count () AS.log GROUP BY date, c-ip, cs-uri-stem HAVING Hitler> 50 SİPARA GÖRE İstasyona Göre Açıklama "-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
2017-08-06 20:58



Bunlara baktım ve onları özellikle yararlı bulmuyordum. Çoğunlukla "uzlaşmayı buluyorlar" ve bu gerçekten bizim amacımız değil (taviz vermedik) - Jeff Atwood


LogParser ile nasıl yapılacağını bilmiyorum ama 404'leri alan "phpMyAdmin" (ya da diğer yaygın zenginlikler) gibi şeyler için istek dizeleri aramak komut dosyası saldırılarını tanımlamak için iyi bir yol olabilir.


0
2017-08-06 19:32



amaç, bu türden komut dosyasıyla yazılmış saldırıları bulmak değil, ancak bant genişliği ve trafiğe ilişkin sorumsuz / sorunlu istemciler değildir. - Jeff Atwood
Beni incitmek isteyen bir müşterinin problemli bir müşteri olduğunu ve bant genişliğimi kullanmamasını tercih ederim. - BCS