IIS izleme için önerilen LogParser sorguları?


86

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 - hileli web örümcekleri , her saniye yenilemek için ayarlanmış büyük bir sayfaya sahip olan kullanıcılar, kötü yazılmış bir kerelik web hurdacıları, hileli Sayfayı arttırmaya çalışan kullanıcılar, zilyonlarca kez sayarlar.

Bir IIS günlük dosyasına işaret ettiğimizde tuhaflıkları ve anormallikleri tanımlamamıza yardımcı olan birkaç LogParser sorgusu buldum .

URL'ye göre en iyi 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'yi vurdu
--------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

URL’ye göre en çok isabet

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

En iyi bant genişliği ve IP / Kullanıcı Aracısı ile isabet

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 sayısı
------------- --------------------------------------- -------- --------- -----
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ısı ile saat başı en iyi 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 istemci kullanıcı aracısı totbytes sayısı
- ------------- ------------------------------------- ------ -------- ----
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ısı ile saate göre en çok isabet

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
saat istemci kullanıcı aracısı totbayt 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 log dosyasına giden yol gibi olacaktır.

c:\working\sologs\u_ex090708.log

İyi IIS LogParser sorguları için birçok web araması yaptım ve çok az değerli buldum. Yukarıdaki 5, ciddi sorunlu müşterileri tespit etmemizde bize büyük yardım sağlamıştır. Ama merak ediyorum - ne kaçırıyoruz?

IIS günlüklerini (tercihen LogParser sorgularıyla ) istatistiksel anomaliler için mayınları dilimlemek ve kesmek için başka hangi yollar vardır ? Sunucularınızda çalıştırdığınız iyi bir IIS LogParser sorgunuz var mı?



En üst bant genişliği kullanım sorgusunda DISTINCT anahtar sözcüğü bulunur. Bu ne için iyi?
Jakub Šturc

Yanıtlar:


19

Etkinlikleri veya diğer saldırıları hacklemenin iyi bir göstergesi saatteki hata sayısıdır. Aşağıdaki komut dosyası, 25'ten fazla hata kodunun döndürüldüğü tarihleri ​​ve saatleri döndürür . Sitedeki trafik miktarına (ve web uygulamanızın kalitesi ;-)) 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 Durum Hata Hatası
---------- -------- ------ ------
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 IP adresinden tek bir URL’de alışılmadık derecede fazla isabet tespit eder . Bu örnekte, 500'ü seçtim, ancak son vakalar 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 IPAdresi Adres Sayısı
---------- ------------------------------------- ----- ---------- ----
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
...

ikinci sorgu zaten yapıyoruz - birkaç sorgudaki gruplamayı not edin. IP ve Kullanıcı Aracısı tarafından bu, her iki dünyanın en iyisidir, çünkü Kullanıcı Aracısı null ise IP ile aynıdır ve değilse, bu daha fazla bilgidir.
Jeff Atwood

Tamam Jeff, kullanıcı aracısını eklemek mantıklı. Üzgünüz, kısa süreli hafıza hafızası ve Dikkat Eksikliği Bozukluğu. :-)
splattne

yerine havingbir ile Limit nuyum için iyi bir yol için ilk sorgu hale getirebileceğini
BCS

6

Meşru trafiği filtrelemeyi (ve kapsamınızı genişletmeyi) düşünebileceğiniz bir şey cs(Cookie), IIS günlüklerinizde etkinleştirmek , javascript'i kullanarak küçük bir çerez ayarlayan bir kod parçası eklemek ve eklemektir WHERE cs(Cookie)=''.

Küçük kod kodunuz nedeniyle, çerezleri manuel olarak devre dışı bırakmadıkça (insanların küçük bir yüzdesinin yapabileceği) veya söz konusu kullanıcı Javascript'i desteklemeyen bir bot olmadığı sürece (örneğin, wget, httpclient) bir çerez olmalıdır. , vb Javascript'i desteklemiyor).

Bir kullanıcının yüksek hacimli bir etkinliği varsa, ancak çerezleri kabul edip javascript’i etkinleştirmişse, meşru bir kullanıcı olma olasılığı daha yüksek olduğundan, yüksek etkinlik düzeyine sahip, ancak çerez / javascript desteği olmayan bir kullanıcı bulursanız , bir bot olma olasılığı daha yüksektir.


6

Üzgünüm, henüz yorum yapamıyorum bu yüzden cevaplamak zorunda kalıyorum.

'URL’ye göre en iyi bant genişliği kullanımı' sorgusu ile ilgili küçük bir hata var. Çoğu zaman bir sayfa için isteklerinizi alma ve dosya boyutuyla çarpma işlemlerini tamamladığınızda, bu durumda, herhangi bir sorgu parametresine dikkat etmediğiniz için, bazı -çok yanlış sayılar.

Daha doğru bir değer için, MUL (Hits, AvgBytes) yerine ServedBytes yerine SUM (sc-bytes) yapın .




4

En uzun isteklerinizi (kaynak ve / veya sorguları) ve sunucu tarafından alınan en çok baytı olanları aramak isteyebilirsiniz. Ayrıca, alınan baytlara ve IP'ye göre gruplanan bir tane de denerdim, böylece belirli bir istek biçiminin bir IP tarafından tekrar edilip edilmediğini 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, günün bir saati ve dakikası için IP isteme grubunun isimlerini ya da düzenli olarak yinelenen ziyaretler olup olmadığını bulmak için istekte bulunan IP'yi saatin dakikasıyla gruplandırırdım. Bu, saat betiğine göre isabetlerde küçük bir değişiklik olur.

Olmayan herhangi bir programlama sitelerinde, SQL anahtar kelimeler için günlükleri arama da iyi bir fikir gibi şeyler SELECT, UPDATE, DROP, DELETEgibi ve diğer tuhaflıklar FROM sys.tablesO halkası, birlikte ve IP tarafından sayma kullanışlı görünüyor. Bunları içeren çoğu site için, kelimeler URI'nin sorgu bölümünde görünürse nadiren olur, ancak burada yasal olarak URI kökünde ve veri bölümlerinde görünebilirler. Sadece önceden hazırlanmış senaryoları kimin çalıştırdığını görmek için isabet iplerinin tersine çevrilmesini seviyorum. Anlıyorum eğilimindedir .ru, .br, .czve .cn. Yargılamak istemem ama onları daha sonra engelleme eğilimindeyim. Ben bugüne kadar ben diyelim ki pek görmüyorum gerçi Savunma, bu ülkeler genellikle, çoğunlukla, doldurulur .in, .fr, .usveya .auaynı şeyi.

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 Bu sorguların gerçekten doğru çalıştığını doğrulayamıyorum. Onarmaları gerekiyorsa, lütfen onları serbestçe düzenleyin.


3

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

Web sitenizdeki en yeni 20 dosya

logparser -i: FS "c: \ inetpub \ wwwroot * adresinden TOP 20 Yolunu, CreationTime SELECT. * * * CreationTime DESC TARAFINDAN SİPARİŞ" -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

En son 20 değiştirilen dosya

logparser -i: FS "c: \ inetpub \ wwwroot * adresindeki TOPW 20 TOPULU, LastWriteTime SELECT. * * * LastWriteTime DESC TARAFINDAN SİPARİŞ" -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ının silinmesi durumunda)

logparser "(Sayı, URL gibi belirgin TO_LOWERCASE (Cs-uri-kök) SEÇ Ör Hit AS) -1: -rtp URL'SİNİ WHERE sc-durum = 200 GRUP URL SİPARİŞ .log"

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

Tek bir günde aynı sayfaya 50 defadan fazla isabet eden IP adreslerini göster

logparser "(Kont DISTINCT tarih, cs-uri-kök, c-ip SEÇ ex GELEN Hits AS) -rtp Desc Hits TARAFINDAN tarih, c-ip, cs-uri-kök HAVING Hit> 50 SİPARİŞ BY .log GROUP": -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

Onlara baktım ve onları çok yararlı bulmadım. Çoğunlukla "uzlaşmayı buluyorlar" ve bu aslında amacımız değil (taviz vermedik)
Jeff Atwood

0

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


amaç bu tür komut dosyasıyla yapılmış saldırıları bulmak değil, bant genişliği ve trafikle ilgili sorumsuz / sorunlu müşterileri bulmak değildir.
Jeff Atwood

2
Bana zarar vermeye çalışan herhangi bir müşterinin sorunlu bir müşteri olduğunu söyleyebilirim ve bant genişliğimi kullanmalarını istemiyorum.
BCS
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.